July 2020 - Linux-stable-mirror

FAILED: patch "[PATCH] spi: spi-fsl-dspi: Fix lockup if device is removed during SPI" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 7684580d45bd3d84ed9b453a4cadf7a9a5605a3f Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski <krzk(a)kernel.org> Date: Mon, 22 Jun 2020 13:05:40 +0200 Subject: [PATCH] spi: spi-fsl-dspi: Fix lockup if device is removed during SPI transfer During device removal, the driver should unregister the SPI controller and stop the hardware. Otherwise the dspi_transfer_one_message() could wait on completion infinitely. Additionally, calling spi_unregister_controller() first in device removal reverse-matches the probe function, where SPI controller is registered at the end. Fixes: 05209f457069 ("spi: fsl-dspi: add missing clk_disable_unprepare() in dspi_remove()") Reported-by: Vladimir Oltean <olteanv(a)gmail.com> Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> Cc: <stable(a)vger.kernel.org> Link: https://lore.kernel.org/r/20200622110543.5035-1-krzk@kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 58190c94561f..ec0fd0d366eb 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -1434,9 +1434,18 @@ static int dspi_remove(struct platform_device *pdev) struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr); /* Disconnect from the SPI framework */ + spi_unregister_controller(dspi->ctlr); + + /* Disable RX and TX */ + regmap_update_bits(dspi->regmap, SPI_MCR, + SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF, + SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF); + + /* Stop Running */ + regmap_update_bits(dspi->regmap, SPI_MCR, SPI_MCR_HALT, SPI_MCR_HALT); + dspi_release_dma(dspi); clk_disable_unprepare(dspi->clk); - spi_unregister_controller(dspi->ctlr); return 0; }

3 years, 11 months

1
0
0 0

[PATCH 1/2] pinctrl: ingenic: Enhance support for IRQ_TYPE_EDGE_BOTH

by Paul Cercueil

Ingenic SoCs don't natively support registering an interrupt for both rising and falling edges. This has to be emulated in software. Until now, this was emulated by switching back and forth between IRQ_TYPE_EDGE_RISING and IRQ_TYPE_EDGE_FALLING according to the level of the GPIO. While this worked most of the time, when used with GPIOs that need debouncing, some events would be lost. For instance, between the time a falling-edge interrupt happens and the interrupt handler configures the hardware for rising-edge, the level of the pin may have already risen, and the rising-edge event is lost. To address that issue, instead of switching back and forth between IRQ_TYPE_EDGE_RISING and IRQ_TYPE_EDGE_FALLING, we now switch back and forth between IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_LEVEL_HIGH. Since we always switch in the interrupt handler, they actually permit to detect level changes. In the example above, if the pin level rises before switching the IRQ type from IRQ_TYPE_LEVEL_LOW to IRQ_TYPE_LEVEL_HIGH, a new interrupt will raise as soon as the handler exits, and the rising-edge event will be properly detected. Cc: stable(a)vger.kernel.org Fixes: e72394e2ea19 ("pinctrl: ingenic: Merge GPIO functionality") Reported-by: João Henrique <johnnyonflame(a)hotmail.com> Tested-by: João Henrique <johnnyonflame(a)hotmail.com> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- drivers/pinctrl/pinctrl-ingenic.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pinctrl/pinctrl-ingenic.c b/drivers/pinctrl/pinctrl-ingenic.c index fc0d10411aa9..241e563d5814 100644 --- a/drivers/pinctrl/pinctrl-ingenic.c +++ b/drivers/pinctrl/pinctrl-ingenic.c @@ -1813,9 +1813,9 @@ static void ingenic_gpio_irq_ack(struct irq_data *irqd) */ high = ingenic_gpio_get_value(jzgc, irq); if (high) - irq_set_type(jzgc, irq, IRQ_TYPE_EDGE_FALLING); + irq_set_type(jzgc, irq, IRQ_TYPE_LEVEL_LOW); else - irq_set_type(jzgc, irq, IRQ_TYPE_EDGE_RISING); + irq_set_type(jzgc, irq, IRQ_TYPE_LEVEL_HIGH); } if (jzgc->jzpc->info->version >= ID_JZ4760) @@ -1851,7 +1851,7 @@ static int ingenic_gpio_irq_set_type(struct irq_data *irqd, unsigned int type) */ bool high = ingenic_gpio_get_value(jzgc, irqd->hwirq); - type = high ? IRQ_TYPE_EDGE_FALLING : IRQ_TYPE_EDGE_RISING; + type = high ? IRQ_TYPE_LEVEL_LOW : IRQ_TYPE_LEVEL_HIGH; } irq_set_type(jzgc, irqd->hwirq, type); -- 2.27.0

3 years, 11 months

3
3
0 0

[PATCH] irq: Request and release resources for chained IRQs

by David Heidelberg

Hello, is there chance to get this patch included or could be this issue solved with different approach? Actually this patch solve issue on two APQ8064 devices: * Nexus 7 2013 Tested-by: David Heidelberg <david(a)ixit.cz> * Nexus 4 Tested-by: Iskren Chernev Best regards David Heidelberg

3 years, 11 months

4
3
0 0

[RFC PATCH for 5.8 1/4] sched: Fix unreliable rseq cpu_id for new tasks

by Mathieu Desnoyers

While integrating rseq into glibc and replacing glibc's sched_getcpu implementation with rseq, glibc's tests discovered an issue with incorrect __rseq_abi.cpu_id field value right after the first time a newly created process issues sched_setaffinity. For the records, it triggers after building glibc and running tests, and then issuing: for x in {1..2000} ; do posix/tst-affinity-static & done and shows up as: error: Unexpected CPU 2, expected 0 error: Unexpected CPU 2, expected 0 error: Unexpected CPU 2, expected 0 error: Unexpected CPU 2, expected 0 error: Unexpected CPU 138, expected 0 error: Unexpected CPU 138, expected 0 error: Unexpected CPU 138, expected 0 error: Unexpected CPU 138, expected 0 This is caused by the scheduler invoking __set_task_cpu() directly from sched_fork() and wake_up_new_task(), thus bypassing rseq_migrate() which is done by set_task_cpu(). Add the missing rseq_migrate() to both functions. The only other direct use of __set_task_cpu() is done by init_idle(), which does not involve a user-space task. Based on my testing with the glibc test-case, just adding rseq_migrate() to wake_up_new_task() is sufficient to fix the observed issue. Also add it to sched_fork() to keep things consistent. The reason why this never triggered so far with the rseq/basic_test selftest is unclear. The current use of sched_getcpu(3) does not typically require it to be always accurate. However, use of the __rseq_abi.cpu_id field within rseq critical sections requires it to be accurate. If it is not accurate, it can cause corruption in the per-cpu data targeted by rseq critical sections in user-space. Link: https://sourceware.org/pipermail/libc-alpha/2020-July/115816.html Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Florian Weimer <fw(a)deneb.enyo.de> Cc: "Paul E. McKenney" <paulmck(a)linux.ibm.com> Cc: Boqun Feng <boqun.feng(a)gmail.com> Cc: "H . Peter Anvin" <hpa(a)zytor.com> Cc: Paul Turner <pjt(a)google.com> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Neel Natu <neelnatu(a)google.com> Cc: linux-api(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v4.18+ --- kernel/sched/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index ca5db40392d4..86a855bd4d90 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -2962,6 +2962,7 @@ int sched_fork(unsigned long clone_flags, struct task_struct *p) * Silence PROVE_RCU. */ raw_spin_lock_irqsave(&p->pi_lock, flags); + rseq_migrate(p); /* * We're setting the CPU for the first time, we don't migrate, * so use __set_task_cpu(). @@ -3026,6 +3027,7 @@ void wake_up_new_task(struct task_struct *p) * as we're not fully set-up yet. */ p->recent_used_cpu = task_cpu(p); + rseq_migrate(p); __set_task_cpu(p, select_task_rq(p, task_cpu(p), SD_BALANCE_FORK, 0)); #endif rq = __task_rq_lock(p, &rf); -- 2.17.1

3 years, 11 months

2
2
0 0

[PATCH] drm/i915/gt: Pin the rings before marking active

by Chris Wilson

On eviction, we acquire the vm->mutex and then wait on the vma->active. Thereore when binding and pinning the vma, we must follow the same sequennce, lock/pin the vma then mark it active. Otherwise, we mark the vma as active, then wait for the vm->mutex, and meanwhile the evictor waits upon us. Fixes: 8ccfc20a7d56 ("drm/i915/gt: Mark ring->vma as active while pinned") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: <stable(a)vger.kernel.org> # v5.6+ --- drivers/gpu/drm/i915/gt/intel_context.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index e4aece20bc80..52db2bde44a3 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -204,25 +204,25 @@ static int __ring_active(struct intel_ring *ring) { int err; - err = i915_active_acquire(&ring->vma->active); + err = intel_ring_pin(ring); if (err) return err; - err = intel_ring_pin(ring); + err = i915_active_acquire(&ring->vma->active); if (err) - goto err_active; + goto err_pin; return 0; -err_active: - i915_active_release(&ring->vma->active); +err_pin: + intel_ring_unpin(ring); return err; } static void __ring_retire(struct intel_ring *ring) { - intel_ring_unpin(ring); i915_active_release(&ring->vma->active); + intel_ring_unpin(ring); } __i915_active_call -- 2.20.1

3 years, 11 months

2
2
0 0

[PATCH v3] usb: gadget: function: fix missing spinlock in f_uac1_legacy

by qiang.zhang＠windriver.com

From: Zhang Qiang <qiang.zhang(a)windriver.com> Add a missing spinlock protection for play_queue, because the play_queue may be destroyed when the "playback_work" work func and "f_audio_out_ep_complete" callback func operate this paly_queue at the same time. Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Zhang Qiang <qiang.zhang(a)windriver.com> --- v1->v2->v3: Add changelog text and Cc tags. drivers/usb/gadget/function/f_uac1_legacy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/function/f_uac1_legacy.c b/drivers/usb/gadget/function/f_uac1_legacy.c index 349deae7cabd..e2d7f69128a0 100644 --- a/drivers/usb/gadget/function/f_uac1_legacy.c +++ b/drivers/usb/gadget/function/f_uac1_legacy.c @@ -336,7 +336,9 @@ static int f_audio_out_ep_complete(struct usb_ep *ep, struct usb_request *req) /* Copy buffer is full, add it to the play_queue */ if (audio_buf_size - copy_buf->actual < req->actual) { + spin_lock_irq(&audio->lock); list_add_tail(&copy_buf->list, &audio->play_queue); + spin_unlock_irq(&audio->lock); schedule_work(&audio->playback_work); copy_buf = f_audio_buffer_alloc(audio_buf_size); if (IS_ERR(copy_buf)) -- 2.24.1

3 years, 11 months

4
4
0 0

[PATCH 1/4] firmware_loader: EFI firmware loader must handle pre-allocated buffer

by Kees Cook

The EFI platform firmware fallback would clobber any pre-allocated buffers. Instead, correctly refuse to reallocate when too small (as already done in the sysfs fallback), or perform allocation normally when needed. Fixes: e4c2c0ff00ec ("firmware: Add new platform fallback mechanism and firm ware_request_platform()") Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> --- drivers/base/firmware_loader/fallback_platform.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/base/firmware_loader/fallback_platform.c b/drivers/base/firmware_loader/fallback_platform.c index cdd2c9a9f38a..685edb7dd05a 100644 --- a/drivers/base/firmware_loader/fallback_platform.c +++ b/drivers/base/firmware_loader/fallback_platform.c @@ -25,7 +25,10 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 opt_flags) if (rc) return rc; /* rc == -ENOENT when the fw was not found */ - fw_priv->data = vmalloc(size); + if (fw_priv->data && size > fw_priv->allocated_size) + return -ENOMEM; + if (!fw_priv->data) + fw_priv->data = vmalloc(size); if (!fw_priv->data) return -ENOMEM; -- 2.25.1

3 years, 11 months

1
0
0 0

RE: [PATCH] mmc: sdio: fix clock rate setting for SDR12/SDR25 mode

by BOUGH CHEN

> -----Original Message----- > From: Ulf Hansson [mailto:ulf.hansson@linaro.org] > Sent: 2020年7月6日 22:49 > To: BOUGH CHEN <haibo.chen(a)nxp.com> > Cc: Adrian Hunter <adrian.hunter(a)intel.com>; linux-mmc(a)vger.kernel.org; > Pali Rohár <pali(a)kernel.org>; dl-linux-imx <linux-imx(a)nxp.com>; Andy Duan > <fugang.duan(a)nxp.com>; Doug Anderson <dianders(a)chromium.org>; > huyue2(a)yulong.com; Matthias Kaehlcke <mka(a)chromium.org> > Subject: Re: [PATCH] mmc: sdio: fix clock rate setting for SDR12/SDR25 mode > > On Mon, 22 Jun 2020 at 10:30, <haibo.chen(a)nxp.com> wrote: > > > > From: Haibo Chen <haibo.chen(a)nxp.com> > > > > In current code logic, when work in SDR12/SDR25 mode, the final clock > > rate is incorrect, just the legancy 400KHz, because the > > card->sw_caps.sd3_bus_mode do not has the flag SD_MODE_UHS_SDR12 or > > SD_MODE_UHS_SDR25. Besides, SDIO_SPEED_SDR12 is actually value 0, and > > every mode need to config the timing and clock rate, so remove the > > ‘if’ operator. > > > > Signed-off-by: Haibo Chen <haibo.chen(a)nxp.com> > > This looks like a rather serious error, should we tag this for stable? Yes, need to do that. Cc: <stable(a)vger.kernel.org> Best Regards Haibo Chen > > In the meantime, I have applied this for next to get it tested, thanks! > > Kind regards > Uffe > > > > > --- > > drivers/mmc/core/sdio.c | 15 ++++++++------- > > 1 file changed, 8 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c index > > 0e32ca7b9488..7b40553d3934 100644 > > --- a/drivers/mmc/core/sdio.c > > +++ b/drivers/mmc/core/sdio.c > > @@ -176,15 +176,18 @@ static int sdio_read_cccr(struct mmc_card *card, > u32 ocr) > > if (mmc_host_uhs(card->host)) { > > if (data & SDIO_UHS_DDR50) > > > card->sw_caps.sd3_bus_mode > > - |= > SD_MODE_UHS_DDR50; > > + |= > SD_MODE_UHS_DDR50 | SD_MODE_UHS_SDR50 > > + | > > + SD_MODE_UHS_SDR25 | SD_MODE_UHS_SDR12; > > > > if (data & SDIO_UHS_SDR50) > > > card->sw_caps.sd3_bus_mode > > - |= > SD_MODE_UHS_SDR50; > > + |= > SD_MODE_UHS_SDR50 | SD_MODE_UHS_SDR25 > > + | > > + SD_MODE_UHS_SDR12; > > > > if (data & SDIO_UHS_SDR104) > > > card->sw_caps.sd3_bus_mode > > - |= > SD_MODE_UHS_SDR104; > > + |= > SD_MODE_UHS_SDR104 | SD_MODE_UHS_SDR50 > > + | > > + SD_MODE_UHS_SDR25 | SD_MODE_UHS_SDR12; > > } > > > > ret = mmc_io_rw_direct(card, 0, 0, @@ > -537,10 > > +540,8 @@ static int sdio_set_bus_speed_mode(struct mmc_card *card) > > max_rate = min_not_zero(card->quirk_max_rate, > > card->sw_caps.uhs_max_dtr); > > > > - if (bus_speed) { > > - mmc_set_timing(card->host, timing); > > - mmc_set_clock(card->host, max_rate); > > - } > > + mmc_set_timing(card->host, timing); > > + mmc_set_clock(card->host, max_rate); > > > > return 0; > > } > > -- > > 2.17.1 > >

3 years, 11 months

2
1
0 0

[PATCH 1/1] usb: chipidea: core: add wakeup support for extcon

by Peter Chen

From: Peter Chen <peter.chen(a)nxp.com> If wakeup event occurred by extcon event, it needs to call ci_irq again since the first ci_irq calling at extcon notifier only wakes up controller, but do noop for event handling, it causes the extcon use case can't work well from low power mode. Cc: <stable(a)vger.kernel.org> Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID detect") Reported-by: Philippe Schenker <philippe.schenker(a)toradex.com> Tested-by: Philippe Schenker <philippe.schenker(a)toradex.com> Signed-off-by: Peter Chen <peter.chen(a)nxp.com> --- drivers/usb/chipidea/core.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 9a7c53d09ab4..bb133245beed 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -1243,6 +1243,29 @@ static void ci_controller_suspend(struct ci_hdrc *ci) enable_irq(ci->irq); } +/* + * Handle the wakeup interrupt triggered by extcon connector + * We need to call ci_irq again for extcon since the first + * interrupt (wakeup int) only let the controller be out of + * low power mode, but not handle any interrupts. + */ +static void ci_extcon_wakeup_int(struct ci_hdrc *ci) +{ + struct ci_hdrc_cable *cable_id, *cable_vbus; + u32 otgsc = hw_read_otgsc(ci, ~0); + + cable_id = &ci->platdata->id_extcon; + cable_vbus = &ci->platdata->vbus_extcon; + + if (!IS_ERR(cable_id->edev) && ci->is_otg && + (otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) + ci_irq(ci->irq, ci); + + if (!IS_ERR(cable_vbus->edev) && ci->is_otg && + (otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS)) + ci_irq(ci->irq, ci); +} + static int ci_controller_resume(struct device *dev) { struct ci_hdrc *ci = dev_get_drvdata(dev); @@ -1275,6 +1298,7 @@ static int ci_controller_resume(struct device *dev) enable_irq(ci->irq); if (ci_otg_is_fsm_mode(ci)) ci_otg_fsm_wakeup_by_srp(ci); + ci_extcon_wakeup_int(ci); } return 0; -- 2.17.1

3 years, 11 months

1
0
0 0

[PATCH v7 0/2] Renovate memcpy_mcsafe with copy_mc_to_{user, kernel}

by Dan Williams

Changes since v6 [1]: - Collected Tony's Reviewed-by. - Rebased on v5.8-rc3 to address a conflict with commit e3a9e681adb7 ("x86/entry: Fixup bad_iret vs noinstr") No other functional changes, and no other comments since v5. At this point I think I'll go ahead with pushing to -next to get it some soak time for a potential v5.9 merge and catch any other conflicts that might arise in the meantime. Of course, I'll immediately drop it from -next if x86.tip picks it up or naks it. As it stands, nothing queued in x86.tip/master conflicts with these. [1]: http://lore.kernel.org/r/159244031857.1107636.5054974045023236143.stgit@dwi… --- The primary motivation to go touch memcpy_mcsafe() is that the existing benefit of doing slow and careful copies is obviated on newer CPUs. That fact solves the problem of needing to detect machine-check recovery capability. Now the old "mcsafe_key" opt-in to careful copying can be made an opt-out from the default fast copy implementation. The discussion with Linus further made clear that this facility had already lost its x86-machine-check specificity starting with commit 2c89130a56a ("x86/asm/memcpy_mcsafe: Add write-protection-fault handling"). The new changes to not require a "careful copy" further de-emphasizes the role that x86-MCA plays in the implementation to just one more source of recoverable trap during the operation. With the above realizations the name "mcsafe" is no longer accurate and copy_safe() is proposed as its replacement. x86 grows a copy_safe_fast() implementation as a default implementation that is independent of detecting the presence of x86-MCA. --- Dan Williams (2): x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user,kernel}() x86/copy_mc: Introduce copy_mc_generic() arch/powerpc/Kconfig | 2 arch/powerpc/include/asm/string.h | 2 arch/powerpc/include/asm/uaccess.h | 40 +++-- arch/powerpc/lib/Makefile | 2 arch/powerpc/lib/copy_mc_64.S | 4 arch/x86/Kconfig | 2 arch/x86/Kconfig.debug | 2 arch/x86/include/asm/copy_mc_test.h | 75 +++++++++ arch/x86/include/asm/mcsafe_test.h | 75 --------- arch/x86/include/asm/string_64.h | 32 ---- arch/x86/include/asm/uaccess.h | 21 +++ arch/x86/include/asm/uaccess_64.h | 20 -- arch/x86/kernel/cpu/mce/core.c | 8 - arch/x86/kernel/quirks.c | 9 - arch/x86/lib/Makefile | 1 arch/x86/lib/copy_mc.c | 64 ++++++++ arch/x86/lib/copy_mc_64.S | 165 ++++++++++++++++++++ arch/x86/lib/memcpy_64.S | 115 -------------- arch/x86/lib/usercopy_64.c | 21 --- drivers/md/dm-writecache.c | 15 +- drivers/nvdimm/claim.c | 2 drivers/nvdimm/pmem.c | 6 - include/linux/string.h | 9 - include/linux/uaccess.h | 9 + include/linux/uio.h | 10 + lib/Kconfig | 7 + lib/iov_iter.c | 43 +++-- tools/arch/x86/include/asm/mcsafe_test.h | 13 -- tools/arch/x86/lib/memcpy_64.S | 115 -------------- tools/objtool/check.c | 5 - tools/perf/bench/Build | 1 tools/perf/bench/mem-memcpy-x86-64-lib.c | 24 --- tools/testing/nvdimm/test/nfit.c | 48 +++--- .../testing/selftests/powerpc/copyloops/.gitignore | 2 tools/testing/selftests/powerpc/copyloops/Makefile | 6 - .../selftests/powerpc/copyloops/copy_mc_64.S | 1 .../selftests/powerpc/copyloops/memcpy_mcsafe_64.S | 1 37 files changed, 451 insertions(+), 526 deletions(-) rename arch/powerpc/lib/{memcpy_mcsafe_64.S => copy_mc_64.S} (98%) create mode 100644 arch/x86/include/asm/copy_mc_test.h delete mode 100644 arch/x86/include/asm/mcsafe_test.h create mode 100644 arch/x86/lib/copy_mc.c create mode 100644 arch/x86/lib/copy_mc_64.S delete mode 100644 tools/arch/x86/include/asm/mcsafe_test.h delete mode 100644 tools/perf/bench/mem-memcpy-x86-64-lib.c create mode 120000 tools/testing/selftests/powerpc/copyloops/copy_mc_64.S delete mode 120000 tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S

3 years, 11 months

1
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2020