- 12 Jan, 2017 40 commits
-
-
Ard Biesheuvel authored
commit 56e4e76c upstream. The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions refers to the AES round keys as pairs of 64-bit quantities, which causes failures when building the code for big endian. In addition, it byte swaps the input counter unconditionally, while this is only required for little endian builds. So fix both issues. Fixes: 12ac3efe ("arm64/crypto: use crypto instructions to generate AES key schedule") Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Ard Biesheuvel authored
commit 58010fa6 upstream. The AES key schedule generation is mostly endian agnostic, with the exception of the rotation and the incorporation of the round constant at the start of each round. So implement a big endian specific version of that part to make the whole routine big endian compatible. Fixes: 86464859 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions") Signed-off-by:
-
Ard Biesheuvel authored
commit 9c433ad5 upstream. The GHASH key and digest are both pairs of 64-bit quantities, but the GHASH code does not always refer to them as such, causing failures when built for big endian. So replace the 16x1 loads and stores with 2x8 ones. Fixes: b913a640 ("arm64/crypto: improve performance of GHASH algorithm") Signed-off-by:
-
Ard Biesheuvel authored
commit 174122c3 upstream. The SHA256 digest is an array of 8 32-bit quantities, so we should refer to them as such in order for this code to work correctly when built for big endian. So replace 16 byte scalar loads and stores with 4x32 vector ones where appropriate. Fixes: 6ba6c74d ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions") Signed-off-by:
-
Dan Carpenter authored
commit 9e6e7c74 upstream. We added some new locking but forgot to unlock on error. Fixes: 57127645 ("s390/zcrypt: Introduce new SHA-512 based Pseudo Random Generator.") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Dan Carpenter authored
commit 16652a93 upstream. We never set "ret" to RESULT_OK. Fixes: 9f9c4180 ("mmc: mmc_test: add test for non-blocking transfers") Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Tony Lindgren authored
commit bed57030 upstream. I noticed some wakeirq flakeyness with consumer drivers not using autosuspend. For drivers not using autosuspend, the wakeirq may never get unmasked in rpm_suspend() because of irq desc->depth. We are configuring dedicated wakeirqs to start with IRQ_NOAUTOEN as we naturally don't want them running until rpm_suspend() is called. However, when a consumer driver initially calls pm_runtime_get(), we now wrongly start with disable_irq_nosync() call on the dedicated wakeirq that is disabled to start with. This causes desc->depth to toggle between 1 and 2 instead of the usual 0 and 1. This can prevent enable_irq() from unmasking the wakeirq as that only happens at desc->depth 1. This does not necessarily show up with drivers using autosuspend as there is time for disable_irq_nosync() before rpm_suspend() gets called after the autosuspend timeout. Let's fix the issue by adding wirq->status that lazily gets set on the first rpm_suspend(). We also need PM runtime core private functions for dev_pm_enable_wake_irq_check() and dev_pm_disable_wake_irq_check() so we can enable the dedicated wakeirq on the first rpm_suspend(). While at it, let's also fix the comments for dev_pm_enable_wake_irq() and dev_pm_disable_wake_irq(). Those can still be used by the consumer drivers as needed because the IRQ core manages the interrupt usecount for us. Fixes: 4990d4fe (PM / Wakeirq: Add automated device wake IRQ handling) Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Florian Fainelli authored
commit 34c53579 upstream. We did not implement an irq_cpu_offline callback for our irqchip, yet we support setting a given IRQ's affinity. This resulted in interrupts whose affinity mask included CPUs being taken offline not to work correctly once the CPU had been put offline. Fixes: 5f7f0317 ("IRQCHIP: Add new driver for BCM7038-style level 1 interrupt controllers") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: linux-mips@linux-mips.org Cc: jason@lakedaemon.net Cc: marc.zyngier@arm.com Cc: cernekee@gmail.com Cc: jaedon.shin@gmail.com Cc: ralf@linux-mips.org Cc: justinpopo6@gmail.com Link: http://lkml.kernel.org/r/1477948656-12966-2-git-send-email-f.fainelli@gmail.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Dan Carpenter authored
commit a91918cd upstream. This iscsit_tpg_add_portal_group() function is only called from lio_target_tiqn_addtpg(). Both functions free the "tpg" pointer on error so it's a double free bug. The memory is allocated in the caller so it should be freed in the caller and not here. Fixes: e48354ce ("iscsi-target: Add iSCSI fabric support for target v4.1") Signed-off-by:
David Disseldorp <ddiss@suse.de> [ bvanassche: Added "Fix" at start of patch title ] Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Arnd Bergmann authored
commit af15769f upstream. gcc-7 notices that the condition in mvs_94xx_command_active looks suspicious: drivers/scsi/mvsas/mv_94xx.c: In function 'mvs_94xx_command_active': drivers/scsi/mvsas/mv_94xx.c:671:15: error: '<<' in boolean context, did you mean '<' ? [-Werror=int-in-bool-context] This was introduced when the mv_printk() statement got added, and leads to the condition being ignored. This is probably harmless. Changing '&&' to '&' makes the code look reasonable, as we check the command bit before setting and printing it. Fixes: a4632aae ("[SCSI] mvsas: Add new macros and functions") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Charles Keepax authored
commit 5faf071d upstream. Unfortunately, I seem to have missed a case where an IRQ safe spinlock was required, in samsung_i2s_dai_remove, when I fixed up the other calls in this patch: 316fa9e0 ("ASoC: samsung: Use IRQ safe spin lock calls") This causes a lockdep warning when unbinding and rebinding the audio card: [ 104.357664] CPU0 CPU1 [ 104.362174] ---- ---- [ 104.366692] lock(&(&pri_dai->spinlock)->rlock); [ 104.371372] local_irq_disable(); [ 104.377283] lock(&(&substream->self_group.lock)->rlock); [ 104.385259] lock(&(&pri_dai->spinlock)->rlock); [ 104.392469] <Interrupt> [ 104.395072] lock(&(&substream->self_group.lock)->rlock); [ 104.400710] [ 104.400710] *** DEADLOCK *** Fixes: ce8bcdbb ("ASoC: samsung: i2s: Protect more registers with a spinlock") Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Xunlei Pang authored
commit aec0e861 upstream. We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers under kdump, it can be steadily reproduced on several different machines, the dmesg log is like: HP HPSA Driver (v 3.4.16-0) hpsa 0000:02:00.0: using doorbell to reset controller hpsa 0000:02:00.0: board ready after hard reset. hpsa 0000:02:00.0: Waiting for controller to respond to no-op DMAR: Setting identity map for device 0000:02:00.0 [0xe8000 - 0xe8fff] DMAR: Setting identity map for device 0000:02:00.0 [0xf4000 - 0xf4fff] DMAR: Setting identity map for device 0000:02:00.0 [0xbdf6e000 - 0xbdf6efff] DMAR: Setting identity map for device 0000:02:00.0 [0xbdf6f000 - 0xbdf7efff] DMAR: Setting identity map for device 0000:02:00.0 [0xbdf7f000 - 0xbdf82fff] DMAR: Setting identity map for device 0000:02:00.0 [0xbdf83000 - 0xbdf84fff] DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Read] Request device [02:00.0] fault addr fffff000 [fault reason 06] PTE Read access is not set hpsa 0000:02:00.0: controller message 03:00 timed out hpsa 0000:02:00.0: no-op failed; re-trying After some debugging, we found that the fault addr is from DMA initiated at the driver probe stage after reset(not in-flight DMA), and the corresponding pte entry value is correct, the fault is likely due to the old iommu caches of the in-flight DMA before it. Thus we need to flush the old cache after context mapping is setup for the device, where the device is supposed to finish reset at its driver probe stage and no in-flight DMA exists hereafter. I'm not sure if the hardware is responsible for invalidating all the related caches allocated in the iommu hardware before, but seems not the case for hpsa, actually many device drivers have problems in properly resetting the hardware. Anyway flushing (again) by software in kdump kernel when the device gets context mapped which is a quite infrequent operation does little harm. With this patch, the problematic machine can survive the kdump tests. CC: Myron Stowe <myron.stowe@gmail.com> CC: Joseph Szczypek <jszczype@redhat.com> CC: Don Brace <don.brace@microsemi.com> CC: Baoquan He <bhe@redhat.com> CC: Dave Young <dyoung@redhat.com> Fixes: 091d42e4 ("iommu/vt-d: Copy translation tables from old kernel") Fixes: dbcd861f ("iommu/vt-d: Do not re-use domain-ids from the old kernel") Fixes: cf484d0e ("iommu/vt-d: Mark copied context entries") Signed-off-by:
Xunlei Pang <xlpang@redhat.com> Tested-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Jacob Pan authored
commit 65ca7f5f upstream. Different encodings are used to represent supported PASID bits and number of PASID table entries. The current code assigns ecap_pss directly to extended context table entry PTS which is wrong and could result in writing non-zero bits to the reserved fields. IOMMU fault reason 11 will be reported when reserved bits are nonzero. This patch converts ecap_pss to extend context entry pts encoding based on VT-d spec. Chapter 9.4 as follows: - number of PASID bits = ecap_pss + 1 - number of PASID table entries = 2^(pts + 5) Software assigned limit of pasid_max value is also respected to match the allocation limitation of PASID table. cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Tested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Fixes: 2f26e0a9 ('iommu/vt-d: Add basic SVM PASID support') Signed-off-by:
-
Huang Rui authored
commit 432abf68 upstream. The generic command buffer entry is 128 bits (16 bytes), so the offset of tail and head pointer should be 16 bytes aligned and increased with 0x10 per command. When cmd buf is full, head = (tail + 0x10) % CMD_BUFFER_SIZE. So when left space of cmd buf should be able to store only two command, we should be issued one COMPLETE_WAIT additionally to wait all older commands completed. Then the left space should be increased after IOMMU fetching from cmd buf. So left check value should be left <= 0x20 (two commands). Signed-off-by:
Huang Rui <ray.huang@amd.com> Fixes: ac0ea6e9 ('x86/amd-iommu: Improve handling of full command buffer') Signed-off-by:
-
Dan Carpenter authored
commit 24c790fb upstream. We should set "ret" to -EINVAL if iommu_group_get() fails. Fixes: 55c99a4d ("iommu/amd: Use iommu_attach_group()") Signed-off-by:
-
Vladimir Zapolskiy authored
commit bae203d5 upstream. Function mx31_clocks_init() is called during clock intialization on legacy boards with reference clock frequency passed as its input argument, this can be verified by examination of the function declaration found in arch/arm/mach-imx/common.h and actual function users which include that header file. Inside CCF driver the function ignores its input argument, by chance the used value in the function body is the same as input arguments on side of all callers. Fixes: d9388c84 ("clk: imx31: Do not call mxc_timer_init twice when booting with DT") Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Reviewed-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Pan Bian authored
commit 20979202 upstream. Fix bug https://bugzilla.kernel.org/show_bug.cgi?id=188561. Function wm831x_clkout_is_prepared() returns "true" when it fails to read CLOCK_CONTROL_1. "true" means the device is already prepared. So return "true" on the read failure seems improper. Signed-off-by:
Pan Bian <bianpan2016@163.com> Acked-by:
-
Guenter Roeck authored
commit 4fccd4a1 upstream. Fix overflows seen when writing into fan speed limit attributes. Also fix crash due to division by zero, seen when certain very large values (such as 2147483648, or 0x80000000) are written into fan speed limit attributes. Fixes: 594fbe71 ("Add support for GMT G762/G763 PWM fan controllers") Cc: Arnaud Ebalard <arno@natisbad.org> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guenter Roeck authored
commit c0d04e91 upstream. Fix overflows seen when writing voltage and temperature limit attributes. The value passed to DIV_ROUND_CLOSEST() needs to be clamped, and the value parameter passed to nct7802_write_fan_min() is an unsigned long. Also, writing values larger than 2700000 into a fan limit attribute results in writing 0 into the chip's limit registers. The exact behavior when writing this value is unspecified. For consistency, report a limit of 1350000 if the chip register reads 0. This may be wrong, and the chip behavior should be verified with the actual chip, but it is better than reporting a value of 0 (which, when written, results in writing a value of 0x1fff into the chip register). Fixes: 3434f378 ("hwmon: Driver for Nuvoton NCT7802Y") Reviewed-by:
-
Guenter Roeck authored
commit e36ce99e upstream. Module test reports: temp1_max: Suspected overflow: [160000 vs. 0] temp1_min: Suspected overflow: [160000 vs. 0] This is seen because the values passed when writing temperature limits are unbound. Reviewed-by:
-
Jared Bents authored
commit 4538bfbf upstream. Converts the unsigned temperature values from the i2c read to be sign extended as defined in the datasheet so that negative temperatures are properly read. Fixes: 28e6274d ("hwmon: (amc6821) Avoid forward declaration") Signed-off-by:
Jared Bents <jared.bents@rockwellcollins.com> Signed-off-by:
Matt Weber <matthew.weber@rockwellcollins.com> [groeck: Dropped unnecessary continuation line] Signed-off-by:
-
Javier Martinez Canillas authored
commit 13edb767 upstream. If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/hwmon/scpi-hwmon.ko | grep alias $ After this patch: $ modinfo drivers/hwmon/scpi-hwmon.ko | grep alias alias: of:N*T*Carm,scpi-sensorsC* alias: of:N*T*Carm,scpi-sensors Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Fixes: ea98b29a ("hwmon: Support sensors exported via ARM SCP interface") Signed-off-by:
-
Guenter Roeck authored
commit 328cf692 upstream. If CONFIG_ETRAX_AXISFLASHMAP is not configured, the flash rescue image object file is empty. With recent versions of binutils, this results in the following build error. cris-linux-objcopy: error: the input file 'arch/cris/boot/rescue/rescue.o' has no sections This is seen, for example, when trying to build cris:allnoconfig with recently generated toolchains. Since it does not make sense to build a flash rescue image if there is no flash, only build it if CONFIG_ETRAX_AXISFLASHMAP is enabled. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Fixes: 66ab3a74 ("CRIS: Merge machine dependent boot/compressed ..") Signed-off-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
-
Nicolas Iooss authored
commit 31b23982 upstream. The word "background" contains 10 characters so the third argument of strncmp() need to be 10 in order to match this prefix correctly. Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Fixes: 855aed12 ("ath10k: add spectral scan feature") Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Arnd Bergmann authored
[resolves a messed up backport, so no matching upstream commit] The backport of upstream commit 777c6e0d ("hotplug: Make register and unregister notifier API symmetric") to linux-4.4.y introduced a harmless warning in 'allnoconfig' builds as spotted by kernelci.org: kernel/cpu.c:226:13: warning: 'cpu_notify_nofail' defined but not used [-Wunused-function] So far, this is the only stable tree that is affected, as linux-4.6 and higher contain commit 98458172 ("cpu/hotplug: Split out cpu down functions") that makes the function used in all configurations, while older longterm releases so far don't seem to have a backport of 777c6e0d. The fix for the warning is trivial: move the unused function back into the #ifdef section where it was before. Link: https://kernelci.org/build/id/586fcacb59b514049ef6c3aa/logs/ Fixes: 1c0f4e0e ("hotplug: Make register and unregister notifier API symmetric") in v4.4.y Signed-off-by:
-
Felipe Balbi authored
commit 19ec3123 upstream. Let's call dwc3_ep0_prepare_one_trb() explicitly because there are occasions where we will need more than one TRB to handle an EP0 transfer. A follow-up patch will fix one bug related to multiple-TRB Data Phases when it comes to mapping/unmapping requests for DMA. Reported-by:
Janusz Dziedzic <januszx.dziedzic@linux.intel.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Felipe Balbi authored
commit 7931ec86 upstream. For now this is just a cleanup patch, no functional changes. We will be using the new function to fix a bug introduced long ago by commit 0416e494 ("usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced") and further worsened by commit c0bd5456 ("usb: dwc3: ep0: handle non maxpacket aligned transfers > 512") Reported-by:
-
Felipe Balbi authored
commit d6214592 upstream. commit 0416e494 ("usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced") introduced a bug where we would leak DMA resources which would cause us to starve the system of them resulting in failing DMA transfers. Fix the bug by making sure that we always unmap EP0 requests since those are *always* mapped. Fixes: 0416e494 ("usb: dwc3: ep0: correct cache sync issue in case of ep0_bounced") Cc: <stable@vger.kernel.org> Tested-by:
Tomasz Medrek <tomaszx.medrek@intel.com> Reported-by:
-
Eva Rachel Retuya authored
commit b321a38d upstream. The oversampling ratio is controlled using the oversampling pins, OS [2:0] with OS2 being the MSB control bit, and OS0 the LSB control bit. The gpio connected to the OS2 pin is not being set correctly, only OS0 and OS1 pins are being set. Fix the typo to allow proper control of the oversampling pins. Signed-off-by:
Eva Rachel Retuya <eraretuya@gmail.com> Fixes: b9618c0c ("staging: IIO: ADC: New driver for AD7606/AD7606-6/AD7606-4") Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Alexander Usyskin authored
commit 5026c9cb upstream. Adjust function name in KDoc. Fixes: d49dc5e7 (mei: bus: use mei_cldev_ prefix for the API functions) Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Johan Hovold authored
commit e35d6d7c upstream. Bind to the interface, but do not register any ports, after having downloaded the firmware. The device will still disconnect and re-enumerate, but this way we avoid an error messages from being logged as part of the process: io_ti: probe of 1-1.3:1.0 failed with error -5 Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 015105b1 upstream. Make sure to drop the references taken by of_parse_phandle() and bus_find_device() before returning from am335x_get_phy_control(). Note that there is no guarantee that the devres-managed struct phy_control will be valid for the lifetime of the sibling phy device regardless of this change. Fixes: 3bb869c8 ("usb: phy: Add AM335x PHY driver") Acked-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit dc8ee9db upstream. The parent clock of the HSUSB clock is the HP clock, not the MP clock. Fixes: c7bab9f9 ("ARM: shmobile: r8a7794: Add USB clocks to device tree") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Pan Bian authored
commit 3c3dd1e0 upstream. Function klsi_105_open() calls usb_control_msg() (to "enable read") and checks its return value. When the return value is unexpected, it only assigns the error code to the return variable retval, but does not terminate the exception path. This patch fixes the bug by inserting "goto err_generic_close;" when the call to usb_control_msg() fails. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Takashi Iwai authored
commit 4763601a upstream. The function returns -EINVAL even if it builds the stream properly. The bogus error code sneaked in during the code refactoring, but it wasn't noticed until now since the returned error code itself is ignored in anyway. Kill it here, but there is no behavior change by this patch, obviously. Fixes: e5779998 ('ALSA: usb-audio: refactor code') Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jérémy Lefaure authored
commit 5563bb57 upstream. The function bfin_fifo_offset is defined but not used: drivers/usb/musb/blackfin.c:36:12: warning: ‘bfin_fifo_offset’ defined but not used [-Wunused-function] static u32 bfin_fifo_offset(u8 epnum) ^~~~~~~~~~~~~~~~ Adding bfin_fifo_offset to bfin_ops fixes this warning and allows musb core to call this function instead of default_fifo_offset. Fixes: cc92f681 ("usb: musb: Populate new IO functions for blackfin") Signed-off-by:
Jérémy Lefaure <jeremy.lefaure@lse.epita.fr> Signed-off-by:
-
Geert Uytterhoeven authored
commit 3bc02bce upstream. If CONFIG_PM=n: drivers/usb/core/hub.c:107: warning: ‘hub_usb3_port_prepare_disable’ declared inline after being called drivers/usb/core/hub.c:107: warning: previous declaration of ‘hub_usb3_port_prepare_disable’ was here To fix this, move hub_port_disable() after hub_usb3_port_prepare_disable(), and adjust forward declarations. Fixes: 37be6676 ("usb: hub: Fix auto-remount of safely removed or ejected USB-3 devices") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Tony Lindgren authored
commit 8c300fe2 upstream. When unloading omap2430, we can get the following splat: WARNING: CPU: 1 PID: 295 at kernel/irq/manage.c:1478 __free_irq+0xa8/0x2c8 Trying to free already-free IRQ 4 ... [<c01a8b78>] (free_irq) from [<bf0aea84>] (musbhs_dma_controller_destroy+0x28/0xb0 [musb_hdrc]) [<bf0aea84>] (musbhs_dma_controller_destroy [musb_hdrc]) from [<bf09f88c>] (musb_remove+0xf0/0x12c [musb_hdrc]) [<bf09f88c>] (musb_remove [musb_hdrc]) from [<c056a384>] (platform_drv_remove+0x24/0x3c) ... This is because the irq number in use is 260 nowadays, and the dma controller is using u8 instead of int. Fixes: 6995eb68 ("USB: musb: enable low level DMA operation for Blackfin") Signed-off-by:
-
Heikki Krogerus authored
commit 8f8983a5 upstream. Intel Gemini Lake SoC has the same DWC3 than Broxton. Add the new ID to the supported Devices. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
OGAWA Hirofumi authored
commit 1c111b6c upstream. Current abort operation has race. xhci_handle_command_timeout() xhci_abort_cmd_ring() xhci_write_64(CMD_RING_ABORT) xhci_handshake(5s) do { check CMD_RING_RUNNING udelay(1) ... COMP_CMD_ABORT event COMP_CMD_STOP event xhci_handle_stopped_cmd_ring() restart cmd_ring CMD_RING_RUNNING become 1 again } while () return -ETIMEDOUT xhci_write_64(CMD_RING_ABORT) /* can abort random command */ To do abort operation correctly, we have to wait both of COMP_CMD_STOP event and negation of CMD_RING_RUNNING. But like above, while timeout handler is waiting negation of CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout handler never be notice negation of CMD_RING_RUNNING, and retry of CMD_RING_ABORT can abort random command (BTW, I guess retry of CMD_RING_ABORT was workaround of this race). To fix this race, this moves xhci_handle_stopped_cmd_ring() to xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event. At this point, timeout handler is owner of cmd_ring, and safely restart cmd_ring by using xhci_handle_stopped_cmd_ring(). [FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE operation] [locks edited as patch is rebased on other locking fixes -Mathias] Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
