July 2019 - Linux-stable-mirror

[PATCH v2] mtd: rawnand: micron: handle on-die "ECC-off" devices correctly

by Marco Felsch

Some devices are supposed to do not support on-die ECC but experience shows that internal ECC machinery can actually be enabled through the "SET FEATURE (EFh)" command, even if a read of the "READ ID Parameter Tables" returns that it is not. Currently, the driver checks the "READ ID Parameter" field directly after having enabled the feature. If the check fails it returns immediately but leaves the ECC on. When using buggy chips like MT29F2G08ABAGA and MT29F2G08ABBGA, all future read/program cycles will go through the on-die ECC, confusing the host controller which is supposed to be the one handling correction. To address this in a common way we need to turn off the on-die ECC directly after reading the "READ ID Parameter" and before checking the "ECC status". Cc: stable(a)vger.kernel.org Fixes: dbc44edbf833 ("mtd: rawnand: micron: Fix on-die ECC detection logic") Signed-off-by: Marco Felsch <m.felsch(a)pengutronix.de> Reviewed-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- v2: - adapt commit message according Miquel comments - add fixes, stable tags - add Boris rb-tag drivers/mtd/nand/raw/nand_micron.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c index 1622d3145587..fb199ad2f1a6 100644 --- a/drivers/mtd/nand/raw/nand_micron.c +++ b/drivers/mtd/nand/raw/nand_micron.c @@ -390,6 +390,14 @@ static int micron_supports_on_die_ecc(struct nand_chip *chip) (chip->id.data[4] & MICRON_ID_INTERNAL_ECC_MASK) != 0x2) return MICRON_ON_DIE_UNSUPPORTED; + /* + * It seems that there are devices which do not support ECC official. + * At least the MT29F2G08ABAGA / MT29F2G08ABBGA devices supports + * enabling the ECC feature but don't reflect that to the READ_ID table. + * So we have to guarantee that we disable the ECC feature directly + * after we did the READ_ID table command. Later we can evaluate the + * ECC_ENABLE support. + */ ret = micron_nand_on_die_ecc_setup(chip, true); if (ret) return MICRON_ON_DIE_UNSUPPORTED; @@ -398,13 +406,13 @@ static int micron_supports_on_die_ecc(struct nand_chip *chip) if (ret) return MICRON_ON_DIE_UNSUPPORTED; - if (!(id[4] & MICRON_ID_ECC_ENABLED)) - return MICRON_ON_DIE_UNSUPPORTED; - ret = micron_nand_on_die_ecc_setup(chip, false); if (ret) return MICRON_ON_DIE_UNSUPPORTED; + if (!(id[4] & MICRON_ID_ECC_ENABLED)) + return MICRON_ON_DIE_UNSUPPORTED; + ret = nand_readid_op(chip, 0, id, sizeof(id)); if (ret) return MICRON_ON_DIE_UNSUPPORTED; -- 2.20.1

5 years, 4 months

2
3
0 0

[PATCH 03/17] drm/i915: Flush extra hard after writing relocations through the GTT

by Chris Wilson

Recently discovered in commit bdae33b8b82b ("drm/i915: Use maximum write flush for pwrite_gtt") was that we needed to our full write barrier before changing the GGTT PTE to ensure that our indirect writes through the GTT landed before the PTE changed (and the writes end up in a different page). That also applies to our GGTT relocation path. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 8a2047c4e7c3..01901dad33f7 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1019,11 +1019,12 @@ static void reloc_cache_reset(struct reloc_cache *cache) kunmap_atomic(vaddr); i915_gem_object_finish_access((struct drm_i915_gem_object *)cache->node.mm); } else { - wmb(); + struct i915_ggtt *ggtt = cache_to_ggtt(cache); + + intel_gt_flush_ggtt_writes(ggtt->vm.gt); io_mapping_unmap_atomic((void __iomem *)vaddr); - if (cache->node.allocated) { - struct i915_ggtt *ggtt = cache_to_ggtt(cache); + if (cache->node.allocated) { ggtt->vm.clear_range(&ggtt->vm, cache->node.start, cache->node.size); @@ -1078,6 +1079,7 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj, void *vaddr; if (cache->vaddr) { + intel_gt_flush_ggtt_writes(ggtt->vm.gt); io_mapping_unmap_atomic((void __force __iomem *) unmask_page(cache->vaddr)); } else { struct i915_vma *vma; @@ -1119,7 +1121,6 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj, offset = cache->node.start; if (cache->node.allocated) { - wmb(); ggtt->vm.insert_page(&ggtt->vm, i915_gem_object_get_dma_address(obj, page), offset, I915_CACHE_NONE, 0); -- 2.22.0

5 years, 4 months

1
0
0 0

[PATCH v4 2/6] coresight: etm4x: use explicit barriers on enable/disable

by Andrew Murray

Synchronization is recommended before disabling the trace registers to prevent any start or stop points being speculative at the point of disabling the unit (section 7.3.77 of ARM IHI 0064D). Synchronization is also recommended after programming the trace registers to ensure all updates are committed prior to normal code resuming (section 4.3.7 of ARM IHI 0064D). Let's ensure these syncronization points are present in the code and clearly commented. Note that we could rely on the barriers in CS_LOCK and coresight_disclaim_device_unlocked or the context switch to user space - however coresight may be of use in the kernel. On armv8 the mb macro is defined as dsb(sy) - Given that the etm4x is only used on armv8 let's directly use dsb(sy) instead of mb(). This removes some ambiguity and makes it easier to correlate the code with the TRM. Signed-off-by: Andrew Murray <andrew.murray(a)arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> CC: stable(a)vger.kernel.org --- drivers/hwtracing/coresight/coresight-etm4x.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c index 7ad15651e069..ec9468880c71 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x.c +++ b/drivers/hwtracing/coresight/coresight-etm4x.c @@ -188,6 +188,13 @@ static int etm4_enable_hw(struct etmv4_drvdata *drvdata) dev_err(etm_dev, "timeout while waiting for Idle Trace Status\n"); + /* + * As recommended by section 4.3.7 ("Synchronization when using the + * memory-mapped interface") of ARM IHI 0064D + */ + dsb(sy); + isb(); + done: CS_LOCK(drvdata->base); @@ -453,8 +460,12 @@ static void etm4_disable_hw(void *info) /* EN, bit[0] Trace unit enable bit */ control &= ~0x1; - /* make sure everything completes before disabling */ - mb(); + /* + * Make sure everything completes before disabling, as recommended + * by section 7.3.77 ("TRCVICTLR, ViewInst Main Control Register, + * SSTATUS") of ARM IHI 0064D + */ + dsb(sy); isb(); writel_relaxed(control, drvdata->base + TRCPRGCTLR); -- 2.21.0

5 years, 4 months

1
0
0 0

patch "driver core: platform: return -ENXIO for missing GpioInt" added to driver-core-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled driver core: platform: return -ENXIO for missing GpioInt to my driver-core git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git in the driver-core-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 46c42d844211ef5902e32aa507beac0817c585e9 Mon Sep 17 00:00:00 2001 From: Brian Norris <briannorris(a)chromium.org> Date: Mon, 29 Jul 2019 13:49:54 -0700 Subject: driver core: platform: return -ENXIO for missing GpioInt Commit daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in platform_get_irq()") broke the Embedded Controller driver on most LPC Chromebooks (i.e., most x86 Chromebooks), because cros_ec_lpc expects platform_get_irq() to return -ENXIO for non-existent IRQs. Unfortunately, acpi_dev_gpio_irq_get() doesn't follow this convention and returns -ENOENT instead. So we get this error from cros_ec_lpc: couldn't retrieve IRQ number (-2) I see a variety of drivers that treat -ENXIO specially, so rather than fix all of them, let's fix up the API to restore its previous behavior. I reported this on v2 of this patch: https://lore.kernel.org/lkml/20190220180538.GA42642@google.com/ but apparently the patch had already been merged before v3 got sent out: https://lore.kernel.org/lkml/20190221193429.161300-1-egranata@chromium.org/ and the result is that the bug landed and remains unfixed. I differ from the v3 patch by: * allowing for ret==0, even though acpi_dev_gpio_irq_get() specifically documents (and enforces) that 0 is not a valid return value (noted on the v3 review) * adding a small comment Reported-by: Brian Norris <briannorris(a)chromium.org> Reported-by: Salvatore Bellizzi <salvatore.bellizzi(a)linux.seppia.net> Cc: Enrico Granata <egranata(a)chromium.org> Cc: <stable(a)vger.kernel.org> Fixes: daaef255dc96 ("driver: platform: Support parsing GpioInt 0 in platform_get_irq()") Signed-off-by: Brian Norris <briannorris(a)chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Acked-by: Enrico Granata <egranata(a)google.com> Link: https://lore.kernel.org/r/20190729204954.25510-1-briannorris@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/base/platform.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 506a0175a5a7..ec974ba9c0c4 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -157,8 +157,13 @@ int platform_get_irq(struct platform_device *dev, unsigned int num) * the device will only expose one IRQ, and this fallback * allows a common code path across either kind of resource. */ - if (num == 0 && has_acpi_companion(&dev->dev)) - return acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num); + if (num == 0 && has_acpi_companion(&dev->dev)) { + int ret = acpi_dev_gpio_irq_get(ACPI_COMPANION(&dev->dev), num); + + /* Our callers expect -ENXIO for missing IRQs. */ + if (ret >= 0 || ret == -EPROBE_DEFER) + return ret; + } return -ENXIO; #endif -- 2.22.0

5 years, 4 months

1
0
0 0

[PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring

by Jian-Hong Pan

Each skb as the element in RX ring was expected with sized buffer 8216 (RTK_PCI_RX_BUF_SIZE) bytes. However, the skb buffer's true size is 16640 bytes for alignment after allocated, x86_64 for example. And, the difference will be enlarged 512 times (RTK_MAX_RX_DESC_NUM). To prevent that much wasted memory, this patch follows David's suggestion [1] and uses general buffer arrays, instead of skbs as the elements in RX ring. [1] https://www.spinics.net/lists/linux-wireless/msg187870.html Signed-off-by: Jian-Hong Pan <jian-hong(a)endlessm.com> Cc: <stable(a)vger.kernel.org> --- drivers/net/wireless/realtek/rtw88/pci.c | 132 +++++++++++++---------- drivers/net/wireless/realtek/rtw88/pci.h | 2 +- 2 files changed, 75 insertions(+), 59 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c index 23dd06afef3d..e953010f0179 100644 --- a/drivers/net/wireless/realtek/rtw88/pci.c +++ b/drivers/net/wireless/realtek/rtw88/pci.c @@ -111,25 +111,49 @@ static void rtw_pci_free_tx_ring(struct rtw_dev *rtwdev, tx_ring->r.head = NULL; } +static struct rtw_pci_rx_buffer_desc *rtw_pci_get_rx_desc( + struct rtw_pci_rx_ring *rx_ring, + u32 idx) +{ + struct rtw_pci_rx_buffer_desc *buf_desc; + u32 desc_sz = rx_ring->r.desc_size; + + buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head + + idx * desc_sz); + return buf_desc; +} + +static dma_addr_t rtw_pci_get_rx_bufdma(struct rtw_pci_rx_ring *rx_ring, + u32 idx) +{ + struct rtw_pci_rx_buffer_desc *buf_desc; + dma_addr_t dma; + + buf_desc = rtw_pci_get_rx_desc(rx_ring, idx); + dma = le32_to_cpu(buf_desc->dma); + + return dma; +} + static void rtw_pci_free_rx_ring(struct rtw_dev *rtwdev, struct rtw_pci_rx_ring *rx_ring) { struct pci_dev *pdev = to_pci_dev(rtwdev->dev); - struct sk_buff *skb; + u8 *buf; dma_addr_t dma; u8 *head = rx_ring->r.head; int buf_sz = RTK_PCI_RX_BUF_SIZE; int ring_sz = rx_ring->r.desc_size * rx_ring->r.len; - int i; + u32 i; for (i = 0; i < rx_ring->r.len; i++) { - skb = rx_ring->buf[i]; - if (!skb) + buf = rx_ring->buf[i]; + if (!buf) continue; - dma = *((dma_addr_t *)skb->cb); - pci_unmap_single(pdev, dma, buf_sz, PCI_DMA_FROMDEVICE); - dev_kfree_skb(skb); + dma = rtw_pci_get_rx_bufdma(rx_ring, i); + pci_unmap_single(pdev, dma, buf_sz, DMA_FROM_DEVICE); + devm_kfree(rtwdev->dev, buf); rx_ring->buf[i] = NULL; } @@ -180,27 +204,24 @@ static int rtw_pci_init_tx_ring(struct rtw_dev *rtwdev, return 0; } -static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb, - struct rtw_pci_rx_ring *rx_ring, - u32 idx, u32 desc_sz) +static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, u8 *buf, + struct rtw_pci_rx_ring *rx_ring, u32 idx) { struct pci_dev *pdev = to_pci_dev(rtwdev->dev); struct rtw_pci_rx_buffer_desc *buf_desc; int buf_sz = RTK_PCI_RX_BUF_SIZE; dma_addr_t dma; - if (!skb) + if (!buf) return -EINVAL; - dma = pci_map_single(pdev, skb->data, buf_sz, PCI_DMA_FROMDEVICE); + dma = pci_map_single(pdev, buf, buf_sz, DMA_FROM_DEVICE); if (pci_dma_mapping_error(pdev, dma)) return -EBUSY; - *((dma_addr_t *)skb->cb) = dma; - buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head + - idx * desc_sz); - memset(buf_desc, 0, sizeof(*buf_desc)); + buf_desc = rtw_pci_get_rx_desc(rx_ring, idx); buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE); + buf_desc->total_pkt_size = cpu_to_le16(0); buf_desc->dma = cpu_to_le32(dma); return 0; @@ -208,7 +229,7 @@ static int rtw_pci_reset_rx_desc(struct rtw_dev *rtwdev, struct sk_buff *skb, static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma, struct rtw_pci_rx_ring *rx_ring, - u32 idx, u32 desc_sz) + u32 idx) { struct device *dev = rtwdev->dev; struct rtw_pci_rx_buffer_desc *buf_desc; @@ -216,10 +237,9 @@ static void rtw_pci_sync_rx_desc_device(struct rtw_dev *rtwdev, dma_addr_t dma, dma_sync_single_for_device(dev, dma, buf_sz, DMA_FROM_DEVICE); - buf_desc = (struct rtw_pci_rx_buffer_desc *)(rx_ring->r.head + - idx * desc_sz); - memset(buf_desc, 0, sizeof(*buf_desc)); + buf_desc = rtw_pci_get_rx_desc(rx_ring, idx); buf_desc->buf_size = cpu_to_le16(RTK_PCI_RX_BUF_SIZE); + buf_desc->total_pkt_size = cpu_to_le16(0); buf_desc->dma = cpu_to_le32(dma); } @@ -228,12 +248,12 @@ static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev, u8 desc_size, u32 len) { struct pci_dev *pdev = to_pci_dev(rtwdev->dev); - struct sk_buff *skb = NULL; + u8 *buf = NULL; dma_addr_t dma; u8 *head; int ring_sz = desc_size * len; int buf_sz = RTK_PCI_RX_BUF_SIZE; - int i, allocated; + u32 i, allocated; int ret = 0; head = pci_zalloc_consistent(pdev, ring_sz, &dma); @@ -242,41 +262,39 @@ static int rtw_pci_init_rx_ring(struct rtw_dev *rtwdev, return -ENOMEM; } rx_ring->r.head = head; + rx_ring->r.dma = dma; + rx_ring->r.len = len; + rx_ring->r.desc_size = desc_size; + rx_ring->r.wp = 0; + rx_ring->r.rp = 0; for (i = 0; i < len; i++) { - skb = dev_alloc_skb(buf_sz); - if (!skb) { + buf = devm_kzalloc(rtwdev->dev, buf_sz, GFP_ATOMIC); + if (!buf) { allocated = i; ret = -ENOMEM; goto err_out; } - memset(skb->data, 0, buf_sz); - rx_ring->buf[i] = skb; - ret = rtw_pci_reset_rx_desc(rtwdev, skb, rx_ring, i, desc_size); + rx_ring->buf[i] = buf; + ret = rtw_pci_reset_rx_desc(rtwdev, buf, rx_ring, i); if (ret) { allocated = i; - dev_kfree_skb_any(skb); + devm_kfree(rtwdev->dev, buf); goto err_out; } } - rx_ring->r.dma = dma; - rx_ring->r.len = len; - rx_ring->r.desc_size = desc_size; - rx_ring->r.wp = 0; - rx_ring->r.rp = 0; - return 0; err_out: for (i = 0; i < allocated; i++) { - skb = rx_ring->buf[i]; - if (!skb) + buf = rx_ring->buf[i]; + if (!buf) continue; - dma = *((dma_addr_t *)skb->cb); - pci_unmap_single(pdev, dma, buf_sz, PCI_DMA_FROMDEVICE); - dev_kfree_skb_any(skb); + dma = rtw_pci_get_rx_bufdma(rx_ring, i); + pci_unmap_single(pdev, dma, buf_sz, DMA_FROM_DEVICE); + devm_kfree(rtwdev->dev, buf); rx_ring->buf[i] = NULL; } pci_free_consistent(pdev, ring_sz, head, dma); @@ -776,13 +794,12 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci, struct rtw_pci_rx_ring *ring; struct rtw_rx_pkt_stat pkt_stat; struct ieee80211_rx_status rx_status; - struct sk_buff *skb, *new; + struct sk_buff *skb; u32 cur_wp, cur_rp, tmp; u32 count; u32 pkt_offset; u32 pkt_desc_sz = chip->rx_pkt_desc_sz; - u32 buf_desc_sz = chip->rx_buf_desc_sz; - u32 new_len; + u32 len; u8 *rx_desc; dma_addr_t dma; @@ -799,11 +816,11 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci, cur_rp = ring->r.rp; while (count--) { rtw_pci_dma_check(rtwdev, ring, cur_rp); - skb = ring->buf[cur_rp]; - dma = *((dma_addr_t *)skb->cb); + /* buffer is already filled as rx_desc */ + rx_desc = ring->buf[cur_rp]; + dma = rtw_pci_get_rx_bufdma(ring, cur_rp); dma_sync_single_for_cpu(rtwdev->dev, dma, RTK_PCI_RX_BUF_SIZE, DMA_FROM_DEVICE); - rx_desc = skb->data; chip->ops->query_rx_desc(rtwdev, rx_desc, &pkt_stat, &rx_status); /* offset from rx_desc to payload */ @@ -813,32 +830,31 @@ static void rtw_pci_rx_isr(struct rtw_dev *rtwdev, struct rtw_pci *rtwpci, /* allocate a new skb for this frame, * discard the frame if none available */ - new_len = pkt_stat.pkt_len + pkt_offset; - new = dev_alloc_skb(new_len); - if (WARN_ONCE(!new, "rx routine starvation\n")) + len = pkt_stat.pkt_len + pkt_offset; + skb = dev_alloc_skb(len); + if (WARN_ONCE(!skb, "rx routine starvation\n")) goto next_rp; /* put the DMA data including rx_desc from phy to new skb */ - skb_put_data(new, skb->data, new_len); + skb_put_data(skb, rx_desc, len); if (pkt_stat.is_c2h) { /* pass rx_desc & offset for further operation */ - *((u32 *)new->cb) = pkt_offset; - skb_queue_tail(&rtwdev->c2h_queue, new); + *((u32 *)skb->cb) = pkt_offset; + skb_queue_tail(&rtwdev->c2h_queue, skb); ieee80211_queue_work(rtwdev->hw, &rtwdev->c2h_work); } else { /* remove rx_desc */ - skb_pull(new, pkt_offset); + skb_pull(skb, pkt_offset); - rtw_rx_stats(rtwdev, pkt_stat.vif, new); - memcpy(new->cb, &rx_status, sizeof(rx_status)); - ieee80211_rx_irqsafe(rtwdev->hw, new); + rtw_rx_stats(rtwdev, pkt_stat.vif, skb); + memcpy(skb->cb, &rx_status, sizeof(rx_status)); + ieee80211_rx_irqsafe(rtwdev->hw, skb); } next_rp: - /* new skb delivered to mac80211, re-enable original skb DMA */ - rtw_pci_sync_rx_desc_device(rtwdev, dma, ring, cur_rp, - buf_desc_sz); + /* new skb delivered to mac80211, re-enable original buf DMA */ + rtw_pci_sync_rx_desc_device(rtwdev, dma, ring, cur_rp); /* host read next element in ring */ if (++cur_rp >= ring->r.len) diff --git a/drivers/net/wireless/realtek/rtw88/pci.h b/drivers/net/wireless/realtek/rtw88/pci.h index 87824a4caba9..283685421a64 100644 --- a/drivers/net/wireless/realtek/rtw88/pci.h +++ b/drivers/net/wireless/realtek/rtw88/pci.h @@ -174,7 +174,7 @@ struct rtw_pci_rx_buffer_desc { struct rtw_pci_rx_ring { struct rtw_pci_ring r; - struct sk_buff *buf[RTK_MAX_RX_DESC_NUM]; + u8 *buf[RTK_MAX_RX_DESC_NUM]; }; #define RX_TAG_MAX 8192 -- 2.22.0

5 years, 4 months

4
7
0 0

[PATCH 4.19.y 0/3] usb: dwc3: Prevent requests from being queued twice

by Saranya Gopal

With recent changes in AOSP, adb is now using asynchronous I/O. While adb works good for the most part, there have been issues with adb root/unroot commands which cause adb hang. The issue is caused by a request being queued twice. A series of 3 patches from Felipe Balbi in upstream tree fixes this issue. Felipe Balbi (3): usb: dwc3: gadget: add dwc3_request status tracking usb: dwc3: gadget: prevent dwc3_request from being queued twice usb: dwc3: gadget: remove req->started flag drivers/usb/dwc3/core.h | 11 +++++++++-- drivers/usb/dwc3/gadget.c | 9 ++++++++- drivers/usb/dwc3/gadget.h | 4 ++-- 3 files changed, 19 insertions(+), 5 deletions(-) -- 1.9.1

5 years, 4 months

4
10
0 0

patch "usb: typec: tcpm: Add NULL check before dereferencing config" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: typec: tcpm: Add NULL check before dereferencing config to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 1957de95d425d1c06560069dc7277a73a8b28683 Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux(a)roeck-us.net> Date: Wed, 24 Jul 2019 07:38:32 -0700 Subject: usb: typec: tcpm: Add NULL check before dereferencing config When instantiating tcpm on an NXP OM 13588 board with NXP PTN5110, the following crash is seen when writing into the 'preferred_role' sysfs attribute. Unable to handle kernel NULL pointer dereference at virtual address 00000028 pgd = f69149ad [00000028] *pgd=00000000 Internal error: Oops: 5 [#1] THUMB2 Modules linked in: tcpci tcpm CPU: 0 PID: 1882 Comm: bash Not tainted 5.1.18-sama5-armv7-r2 #4 Hardware name: Atmel SAMA5 PC is at tcpm_try_role+0x3a/0x4c [tcpm] LR is at tcpm_try_role+0x15/0x4c [tcpm] pc : [<bf8000e2>] lr : [<bf8000bd>] psr: 60030033 sp : dc1a1e88 ip : c03fb47d fp : 00000000 r10: dc216190 r9 : dc1a1f78 r8 : 00000001 r7 : df4ae044 r6 : dd032e90 r5 : dd1ce340 r4 : df4ae054 r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : df4ae044 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none Control: 50c53c7d Table: 3efec059 DAC: 00000051 Process bash (pid: 1882, stack limit = 0x6a6d4aa5) Stack: (0xdc1a1e88 to 0xdc1a2000) 1e80: dd05d808 dd1ce340 00000001 00000007 dd1ce340 c03fb4a7 1ea0: 00000007 00000007 dc216180 00000000 00000000 c01e1e03 00000000 00000000 1ec0: c0907008 dee98b40 c01e1d5d c06106c4 00000000 00000000 00000007 c0194e8b 1ee0: 0000000a 00000400 00000000 c01a97db dc22bf00 ffffe000 df4b6a00 df745900 1f00: 00000001 00000001 000000dd c01a9c2f 7aeab3be c0907008 00000000 dc22bf00 1f20: c0907008 00000000 00000000 00000000 00000000 7aeab3be 00000007 dee98b40 1f40: 005dc318 dc1a1f78 00000000 00000000 00000007 c01969f7 0000000a c01a20cb 1f60: dee98b40 c0907008 dee98b40 005dc318 00000000 c0196b9b 00000000 00000000 1f80: dee98b40 7aeab3be 00000074 005dc318 b6f3bdb0 00000004 c0101224 dc1a0000 1fa0: 00000004 c0101001 00000074 005dc318 00000001 005dc318 00000007 00000000 1fc0: 00000074 005dc318 b6f3bdb0 00000004 00000007 00000007 00000000 00000000 1fe0: 00000004 be800880 b6ed35b3 b6e5c746 60030030 00000001 00000000 00000000 [<bf8000e2>] (tcpm_try_role [tcpm]) from [<c03fb4a7>] (preferred_role_store+0x2b/0x5c) [<c03fb4a7>] (preferred_role_store) from [<c01e1e03>] (kernfs_fop_write+0xa7/0x150) [<c01e1e03>] (kernfs_fop_write) from [<c0194e8b>] (__vfs_write+0x1f/0x104) [<c0194e8b>] (__vfs_write) from [<c01969f7>] (vfs_write+0x6b/0x104) [<c01969f7>] (vfs_write) from [<c0196b9b>] (ksys_write+0x43/0x94) [<c0196b9b>] (ksys_write) from [<c0101001>] (ret_fast_syscall+0x1/0x62) Since commit 96232cbc6c994 ("usb: typec: tcpm: support get typec and pd config from device properties"), the 'config' pointer in struct tcpc_dev is optional when registering a Type-C port. Since it is optional, we have to check if it is NULL before dereferencing it. Reported-by: Douglas Gilbert <dgilbert(a)interlog.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Fixes: 96232cbc6c994 ("usb: typec: tcpm: support get typec and pd config from device properties") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Cc: stable <stable(a)vger.kernel.org> Reviewed-by: Jun Li <jun.li(a)nxp.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Link: https://lore.kernel.org/r/1563979112-22483-1-git-send-email-linux@roeck-us.… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/typec/tcpm/tcpm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index fba32d84e578..77f71f602f73 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -379,7 +379,8 @@ static enum tcpm_state tcpm_default_state(struct tcpm_port *port) return SNK_UNATTACHED; else if (port->try_role == TYPEC_SOURCE) return SRC_UNATTACHED; - else if (port->tcpc->config->default_role == TYPEC_SINK) + else if (port->tcpc->config && + port->tcpc->config->default_role == TYPEC_SINK) return SNK_UNATTACHED; /* Fall through to return SRC_UNATTACHED */ } else if (port->port_type == TYPEC_PORT_SNK) { @@ -4114,7 +4115,7 @@ static int tcpm_try_role(const struct typec_capability *cap, int role) mutex_lock(&port->lock); if (tcpc->try_role) ret = tcpc->try_role(tcpc, role); - if (!ret && !tcpc->config->try_role_hw) + if (!ret && (!tcpc->config || !tcpc->config->try_role_hw)) port->try_role = role; port->try_src_count = 0; port->try_snk_count = 0; @@ -4701,7 +4702,7 @@ static int tcpm_copy_caps(struct tcpm_port *port, port->typec_caps.prefer_role = tcfg->default_role; port->typec_caps.type = tcfg->type; port->typec_caps.data = tcfg->data; - port->self_powered = port->tcpc->config->self_powered; + port->self_powered = tcfg->self_powered; return 0; } -- 2.22.0

5 years, 4 months

1
0
0 0

[PATCH] mpt3sas: Use 63-bit DMA addressing on SAS35 HBA

by Suganath Prabu

Although SAS3 & SAS3.5 IT HBA controllers support 64-bit DMA addressing, as per hardware design, DMA address with all 64-bits set (0xFFFFFFFF-FFFFFFFF) results in a firmware fault. Fix: Driver will set 63-bit DMA mask to ensure the above address will not be used. Signed-off-by: Suganath Prabu <suganath-prabu.subramani(a)broadcom.com> --- drivers/scsi/mpt3sas/mpt3sas_base.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c index 6846628..050c0f0 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -2703,6 +2703,8 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc, struct pci_dev *pdev) { u64 required_mask, coherent_mask; struct sysinfo s; + /* Set 63 bit DMA mask for all SAS3 and SAS35 controllers */ + int dma_mask = (ioc->hba_mpi_version_belonged > MPI2_VERSION) ? 63 : 64; if (ioc->is_mcpu_endpoint) goto try_32bit; @@ -2712,17 +2714,17 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc, struct pci_dev *pdev) goto try_32bit; if (ioc->dma_mask) - coherent_mask = DMA_BIT_MASK(64); + coherent_mask = DMA_BIT_MASK(dma_mask); else coherent_mask = DMA_BIT_MASK(32); - if (dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) || + if (dma_set_mask(&pdev->dev, DMA_BIT_MASK(dma_mask)) || dma_set_coherent_mask(&pdev->dev, coherent_mask)) goto try_32bit; ioc->base_add_sg_single = &_base_add_sg_single_64; ioc->sge_size = sizeof(Mpi2SGESimple64_t); - ioc->dma_mask = 64; + ioc->dma_mask = dma_mask; goto out; try_32bit: @@ -2744,7 +2746,7 @@ static int _base_change_consistent_dma_mask(struct MPT3SAS_ADAPTER *ioc, struct pci_dev *pdev) { - if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) { + if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(ioc->dma_mask))) { if (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32))) return -ENODEV; } @@ -4989,7 +4991,7 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc) total_sz += sz; } while (ioc->rdpq_array_enable && (++i < ioc->reply_queue_count)); - if (ioc->dma_mask == 64) { + if (ioc->dma_mask > 32) { if (_base_change_consistent_dma_mask(ioc, ioc->pdev) != 0) { ioc_warn(ioc, "no suitable consistent DMA mask for %s\n", pci_name(ioc->pdev)); -- 1.8.3.1

5 years, 4 months

4
4
0 0

stable-rc/linux-4.9.y boot: 87 boots: 0 failed, 52 passed with 35 offline (v4.9.186-211-ge7a6807764e7)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 87 boots: 0 failed, 52 passed with 35 offline (v4.9.186-211-ge7a6807764e7) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.186-211… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.186-211-ge7a6807764e7 Git Commit: e7a6807764e7f39a1865570cc4f4f81b356c32cd Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 43 unique boards, 21 SoC families, 15 builds out of 197 Offline Platforms: arm64: defconfig: gcc-8 meson-gxbb-odroidc2: 1 offline lab arm: tegra_defconfig: gcc-8 tegra20-iris-512: 1 offline lab exynos_defconfig: gcc-8 exynos5250-arndale: 1 offline lab exynos5420-arndale-octa: 1 offline lab exynos5800-peach-pi: 1 offline lab multi_v7_defconfig: gcc-8 bcm72521-bcm97252sffe: 1 offline lab bcm7445-bcm97445c: 1 offline lab exynos5250-arndale: 1 offline lab exynos5420-arndale-octa: 1 offline lab exynos5800-peach-pi: 1 offline lab imx6dl-wandboard_dual: 1 offline lab imx6dl-wandboard_solo: 1 offline lab imx6q-wandboard: 1 offline lab imx7s-warp: 1 offline lab meson8b-odroidc1: 1 offline lab omap3-beagle: 1 offline lab omap4-panda: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab stih410-b2120: 1 offline lab sun4i-a10-cubieboard: 1 offline lab sun7i-a20-bananapi: 1 offline lab tegra20-iris-512: 1 offline lab vf610-colibri-eval-v3: 1 offline lab omap2plus_defconfig: gcc-8 omap3-beagle: 1 offline lab omap4-panda: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-ifc6410: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab imx_v6_v7_defconfig: gcc-8 imx6dl-wandboard_dual: 1 offline lab imx6dl-wandboard_solo: 1 offline lab imx6q-wandboard: 1 offline lab imx7s-warp: 1 offline lab vf610-colibri-eval-v3: 1 offline lab sunxi_defconfig: gcc-8 sun4i-a10-cubieboard: 1 offline lab sun7i-a20-bananapi: 1 offline lab --- For more info write to <info(a)kernelci.org>

5 years, 4 months

1
0
0 0

stable-rc/linux-4.4.y boot: 80 boots: 1 failed, 46 passed with 32 offline, 1 conflict (v4.4.186-150-g4ff70b6cca1d)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 80 boots: 1 failed, 46 passed with 32 offline, 1 conflict (v4.4.186-150-g4ff70b6cca1d) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.186-150… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.186-150-g4ff70b6cca1d Git Commit: 4ff70b6cca1d8706cd9ed25bc81b0754223f8210 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 38 unique boards, 19 SoC families, 14 builds out of 190 Boot Failure Detected: arm64: defconfig: gcc-8: qcom-qdf2400: 1 failed lab Offline Platforms: arm: tegra_defconfig: gcc-8 tegra20-iris-512: 1 offline lab exynos_defconfig: gcc-8 exynos5250-arndale: 1 offline lab exynos5420-arndale-octa: 1 offline lab exynos5800-peach-pi: 1 offline lab multi_v7_defconfig: gcc-8 bcm72521-bcm97252sffe: 1 offline lab bcm7445-bcm97445c: 1 offline lab exynos5250-arndale: 1 offline lab exynos5420-arndale-octa: 1 offline lab exynos5800-peach-pi: 1 offline lab imx6dl-wandboard_dual: 1 offline lab imx6dl-wandboard_solo: 1 offline lab imx6q-wandboard: 1 offline lab meson8b-odroidc1: 1 offline lab omap3-beagle: 1 offline lab omap4-panda: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab stih410-b2120: 1 offline lab sun4i-a10-cubieboard: 1 offline lab sun7i-a20-bananapi: 1 offline lab tegra20-iris-512: 1 offline lab vf610-colibri-eval-v3: 1 offline lab omap2plus_defconfig: gcc-8 omap3-beagle: 1 offline lab omap4-panda: 1 offline lab qcom_defconfig: gcc-8 qcom-apq8064-ifc6410: 1 offline lab davinci_all_defconfig: gcc-8 da850-evm: 1 offline lab dm365evm,legacy: 1 offline lab imx_v6_v7_defconfig: gcc-8 imx6dl-wandboard_dual: 1 offline lab imx6dl-wandboard_solo: 1 offline lab imx6q-wandboard: 1 offline lab vf610-colibri-eval-v3: 1 offline lab sunxi_defconfig: gcc-8 sun4i-a10-cubieboard: 1 offline lab sun7i-a20-bananapi: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) x86_64: x86_64_defconfig: qemu: lab-linaro-lkft: PASS (gcc-8) lab-mhart: PASS (gcc-8) lab-baylibre: FAIL (gcc-8) lab-drue: PASS (gcc-8) lab-collabora: PASS (gcc-8) --- For more info write to <info(a)kernelci.org>

5 years, 4 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2019