summaryrefslogtreecommitdiffstats
path: root/crypto/crypto_engine.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2019-08-27pinctrl: mvebu: add additional variant for standalone CP115Grzegorz Jaszczyk1-4/+13
With CP115 standalone modules, all MPP configuration are possible. Handle this new possibility thanks to the new "marvell,cp115-standalone-pinctrl" compatible property. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> [<miquel.raynal@bootlin.com>: mention the new compatible in the commit log] Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20190805101607.29811-4-miquel.raynal@bootlin.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-27pinctrl: mvebu: Add CP110 missing pin functionalityKonstantin Porotchkin1-1/+2
Add missing definition for function 0xe on CP-110 MPP-62. The pin function is Data Strobe for SDIO interface. Signed-off-by: Konstantin Porotchkin <kostap@marvell.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20190805101607.29811-2-miquel.raynal@bootlin.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-27dt-bindings: cp110: document the new CP115 pinctrl compatibleGrzegorz Jaszczyk1-2/+2
A new compatible is going to be used for Armada CP115 pinctrl block, document it. Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com> [<miquel.raynal@bootlin.com>: split the documentation out of the driver commit] Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20190805101607.29811-3-miquel.raynal@bootlin.com Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-26pinctrl: bcm2835: Pass irqchip when adding gpiochipLinus Walleij1-30/+25
We need to convert all old gpio irqchips to pass the irqchip setup along when adding the gpio_chip. For more info see drivers/gpio/TODO. For chained irqchips this is a pretty straight-forward conversion. The BCM2835 has multiple parents so let's exploit the new facility in the GPIO_IRQCHIP to actually deal with multiple parents. Cc: Eric Anholt <eric@anholt.net> Cc: Thierry Reding <treding@nvidia.com> [Rebased on changes in the pinctrl tree] Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/20190812062729.1892-1-linus.walleij@linaro.org
2019-08-23pinctrl: meson: meson: Add of_node_put() before returnNishka Dasgupta1-0/+1
Each iteration of for_each_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Link: https://lore.kernel.org/r/20190815060718.3286-1-nishkadg.linux@gmail.com Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-23pinctrl/gpio: Take MUX usage into accountStefan Wahren5-1/+68
The user space like gpioinfo only see the GPIO usage but not the MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which pin is free/safe to use. So take the MUX usage of strict pinmux controllers into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Ramon Fried <rfried.dev@gmail.com> Signed-off-by: Ramon Fried <rfried.dev@gmail.com> Link: https://lore.kernel.org/r/20190814110035.13451-1-ramon.fried@linux.intel.com Acked-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-23dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8150l supportVinod Koul2-0/+3
Add support for the PM8150l GPIO support to the Qualcomm PMIC GPIO binding. Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20190814123512.6017-3-vkoul@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-23dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8150b supportVinod Koul2-0/+4
Add support for the PM8150b GPIO support to the Qualcomm PMIC GPIO binding. Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20190814123512.6017-2-vkoul@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-23dt-bindings: pinctrl: qcom-pmic-gpio: Add pm8150 supportVinod Koul2-0/+5
Add support for the PM8150 GPIO support to the Qualcomm PMIC GPIO binding. Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20190814123512.6017-1-vkoul@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-23pinctrl: amd: disable spurious-firing GPIO IRQsDaniel Drake1-1/+11
When cold-booting Asus X434DA, GPIO 7 is found to be already configured as an interrupt, and the GPIO level is found to be in a state that causes the interrupt to fire. As soon as pinctrl-amd probes, this interrupt fires and invokes amd_gpio_irq_handler(). The IRQ is acked, but no GPIO-IRQ handler was invoked, so the GPIO level being unchanged just causes another interrupt to fire again immediately after. This results in an interrupt storm causing this platform to hang during boot, right after pinctrl-amd is probed. Detect this situation and disable the GPIO interrupt when this happens. This enables the affected platform to boot as normal. GPIO 7 actually is the I2C touchpad interrupt line, and later on, i2c-multitouch loads and re-enables this interrupt when it is ready to handle it. Instead of this approach, I considered disabling all GPIO interrupts at probe time, however that seems a little risky, and I also confirmed that Windows does not seem to have this behaviour: the same 41 GPIO IRQs are enabled under both Linux and Windows, which is a far larger collection than the GPIOs referenced by the DSDT on this platform. Signed-off-by: Daniel Drake <drake@endlessm.com> Link: https://lore.kernel.org/r/20190814090540.7152-1-drake@endlessm.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-23pinctrl: rza2: Include the appropriate headersLinus Walleij1-1/+2
This driver is implementing a GPIO driver so include <linux/gpio/driver.h> and not the legacy API <linux/gpio.h>. When testing it turns out it also relies on implicit inclusion of <linux/io.h> (readw etc) so make sure to include that as well. Cc: Chris Brandt <chris.brandt@renesas.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-23pinctrl: rza2: Drop driver use of consumer flagsLinus Walleij1-7/+7
These flags are for consumers of GPIO lines, not for drivers. Cc: Chris Brandt <chris.brandt@renesas.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-23pinctrl: rza1: Add of_node_put() before returnNishka Dasgupta1-3/+9
Each iteration of for_each_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return in three places. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-23pinctrl: sh-pfc: Include the right headerLinus Walleij1-1/+1
This is a GPIO driver, use the appropriate header <linux/gpio/driver.h> rather than the legacy <linux/gpio.h> header. Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-23pinctrl: sh-pfc: Rollback to mux if required when the gpio is freedYoshihiro Shimoda1-0/+15
Some drivers require switching between function and gpio at run-time. Allow to roll back from gpio to mux when the gpio is freed. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2019-08-21pinctrl: st: Add of_node_put() before returnNishka Dasgupta1-2/+7
Each iteration of for_each_child_of_node puts the previous node, but in the case of a return from the middle of the loop, there is no put, thus causing a memory leak. Hence add an of_node_put before the return in three places. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Link: https://lore.kernel.org/r/20190815060609.3056-1-nishkadg.linux@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-21pinctrl: st: Include the right headerLinus Walleij1-1/+2
The ST pinctrl driver wants to provode a gpio_chip but is not including the header for this, fix the inclusion to use the right header. <linux/of_gpio.h> has to remain as the driver is calling of_get_named_gpio(). Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Maxime Coquelin <maxime.coquelin@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190820111135.10701-1-linus.walleij@linaro.org
2019-08-21pinctrl: rk805: Make structures constantNishka Dasgupta1-2/+2
Static structures rk805_pinctrl_desc and rk805_gpio_chip, of types gpio_chip and pinctrl_desc respectively, are not used except to be copied into the fields of a different variable. Hence make rk805_pinctrl_desc and rk805_gpio_chip both constant to protect them from unintended modification. Issue found with Coccinelle. Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com> Link: https://lore.kernel.org/r/20190819075757.1753-1-nishkadg.linux@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-21pinctrl: tegra: Flush pinctrl writes during resumeSowjanya Komatineni1-0/+4
This patch adds pinctrl register read to flush all the prior pinctrl writes and then adds barrier for pinctrl register read to complete during resume to make sure all pinctrl changes are effective. Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1565984527-5272-3-git-send-email-skomatineni@nvidia.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-21pinctrl: tegra: Fix write barrier placement in pmx_writelSowjanya Komatineni1-1/+3
pmx_writel uses writel which inserts write barrier before the register write. This patch has fix to replace writel with writel_relaxed followed by a readback and memory barrier to ensure write operation is completed for successful pinctrl change. Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Link: https://lore.kernel.org/r/1565984527-5272-2-git-send-email-skomatineni@nvidia.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-21pinctrl: bcm-iproc: Pass irqchip when adding gpiochipLinus Walleij1-14/+19
We need to convert all old gpio irqchips to pass the irqchip setup along when adding the gpio_chip. For more info see drivers/gpio/TODO. For chained irqchips this is a pretty straight-forward conversion. Cc: Pramod Kumar <pramodku@broadcom.com> Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190812132554.18313-1-linus.walleij@linaro.org Acked-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-08-19pinctrl: intel: remap the pin number to gpio offset for irq enabled pinChris Chiu1-1/+24
On Asus X571GT, GPIO 297 is configured as an interrupt and serves for the touchpad. The touchpad will report input events much less than expected after S3 suspend/resume, which results in extremely slow cursor movement. However, the number of interrupts observed from /proc/interrupts increases much more than expected even no touching touchpad. This is due to the value of PADCFG0 of PIN 225 for the interrupt has been changed from 0x80800102 to 0x80100102. The GPIROUTIOXAPIC is toggled on which results in the spurious interrupts. The PADCFG0 of PIN 225 is expected to be saved during suspend, but the 297 is saved instead because the gpiochip_line_is_irq() expect the GPIO offset but what's really passed to it is PIN number. In this case, the /sys/kernel/debug/pinctrl/INT3450:00/gpio-ranges shows 288: INT3450:00 GPIOS [436 - 459] PINS [216 - 239] So gpiochip_line_is_irq() returns true for GPIO offset 297, the suspend routine spuriously saves the content for PIN 297 which we expect to save for PIN 225. This commit maps the PIN number to GPIO offset first in the intel_pinctrl_should_save() to make sure the values for the specific PINs can be correctly saved and then restored. Fixes: c538b9436751 ("pinctrl: intel: Only restore pins that are used by the driver") Signed-off-by: Chris Chiu <chiu@endlessm.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2019-08-18Linux 5.3-rc5v5.3-rc5Linus Torvalds1-1/+1
2019-08-18pinctrl: intel: Allow to request locked padsAndy Shevchenko1-17/+52
Some firmwares would like to protect pads from being modified by OS and at the same time provide them to OS as a resource. So, the driver in such circumstances may request pad and may not change its state. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-08-17MAINTAINERS: Fix Hyperv vIOMMU driver file nameLan Tianyu1-1/+1
The Hyperv vIOMMU file name should be "hyperv-iommu.c" rather than "hyperv_iommu.c". This patch is to fix it. Signed-off-by: Lan Tianyu <Tianyu.Lan@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-17tools: hv: Use the correct style for SPDX License IdentifierNishad Kamdar1-1/+1
This patch corrects the SPDX License Identifier style in the trace header file related to Microsoft Hyper-V client drivers. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46 Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-17tools: hv: fix typos in toolchainAdrian Vladu4-6/+6
Fix typos in the HyperV toolchain. Signed-off-by: Adrian Vladu <avladu@cloudbasesolutions.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Sasha Levin <sashal@kernel.org> Cc: Alessandro Pilotti <apilotti@cloudbasesolutions.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-17tools: hv: fix KVP and VSS daemons exit codeAdrian Vladu2-0/+4
HyperV KVP and VSS daemons should exit with 0 when the '--help' or '-h' flags are used. Signed-off-by: Adrian Vladu <avladu@cloudbasesolutions.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Sasha Levin <sashal@kernel.org> Cc: Alessandro Pilotti <apilotti@cloudbasesolutions.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-17tools: hv: fixed Python pep8/flake8 warnings for lsvmbusAdrian Vladu1-33/+42
Fixed pep8/flake8 python style code for lsvmbus tool. The TAB indentation was on purpose ignored (pep8 rule W191) to make sure the code is complying with the Linux code guideline. The following command doe not show any warnings now: pep8 --ignore=W191 lsvmbus flake8 --ignore=W191 lsvmbus Signed-off-by: Adrian Vladu <avladu@cloudbasesolutions.com> Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Sasha Levin <sashal@kernel.org> Cc: Dexuan Cui <decui@microsoft.com> Cc: Alessandro Pilotti <apilotti@cloudbasesolutions.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-16arm64: ftrace: Ensure module ftrace trampoline is coherent with I-sideWill Deacon1-9/+13
The initial support for dynamic ftrace trampolines in modules made use of an indirect branch which loaded its target from the beginning of a special section (e71a4e1bebaf7 ("arm64: ftrace: add support for far branches to dynamic ftrace")). Since no instructions were being patched, no cache maintenance was needed. However, later in be0f272bfc83 ("arm64: ftrace: emit ftrace-mod.o contents through code") this code was reworked to output the trampoline instructions directly into the PLT entry but, unfortunately, the necessary cache maintenance was overlooked. Add a call to __flush_icache_range() after writing the new trampoline instructions but before patching in the branch to the trampoline. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: James Morse <james.morse@arm.com> Cc: <stable@vger.kernel.org> Fixes: be0f272bfc83 ("arm64: ftrace: emit ftrace-mod.o contents through code") Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2019-08-16x86/boot: Save fields explicitly, zero out everything elseJohn Hubbard1-15/+48
Recent gcc compilers (gcc 9.1) generate warnings about an out of bounds memset, if the memset goes accross several fields of a struct. This generated a couple of warnings on x86_64 builds in sanitize_boot_params(). Fix this by explicitly saving the fields in struct boot_params that are intended to be preserved, and zeroing all the rest. [ tglx: Tagged for stable as it breaks the warning free build there as well ] Suggested-by: Thomas Gleixner <tglx@linutronix.de> Suggested-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190731054627.5627-2-jhubbard@nvidia.com
2019-08-15ALSA: usb-audio: Fix a stack buffer overflow bug in check_input_termHui Peng1-8/+27
`check_input_term` recursively calls itself with input from device side (e.g., uac_input_terminal_descriptor.bCSourceID) as argument (id). In `check_input_term`, if `check_input_term` is called with the same `id` argument as the caller, it triggers endless recursive call, resulting kernel space stack overflow. This patch fixes the bug by adding a bitmap to `struct mixer_build` to keep track of the checked ids and stop the execution if some id has been checked (similar to how parse_audio_unit handles unitid argument). Reported-by: Hui Peng <benquike@gmail.com> Reported-by: Mathias Payer <mathias.payer@nebelwelt.net> Signed-off-by: Hui Peng <benquike@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-08-15io_uring: fix an issue when IOSQE_IO_LINK is inserted into defer listJackie Liu1-7/+9
This patch may fix two issues: First, when IOSQE_IO_DRAIN set, the next IOs need to be inserted into defer list to delay execution, but link io will be actively scheduled to run by calling io_queue_sqe. Second, when multiple LINK_IOs are inserted together with defer_list, the LINK_IO is no longer keep order. |-------------| | LINK_IO | ----> insert to defer_list ----------- |-------------| | | LINK_IO | ----> insert to defer_list ----------| |-------------| | | LINK_IO | ----> insert to defer_list ----------| |-------------| | | NORMAL_IO | ----> insert to defer_list ----------| |-------------| | | queue_work at same time <-----| Fixes: 9e645e1105c ("io_uring: add support for sqe links") Signed-off-by: Jackie Liu <liuyun01@kylinos.cn> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-08-15block: remove REQ_NOWAIT_INLINEJens Axboe3-54/+8
We had a few issues with this code, and there's still a problem around how we deal with error handling for chained/split bios. For now, just revert the code and we'll try again with a thoroug solution. This reverts commits: e15c2ffa1091 ("block: fix O_DIRECT error handling for bio fragments") 0eb6ddfb865c ("block: Fix __blkdev_direct_IO() for bio fragments") 6a43074e2f46 ("block: properly handle IOCB_NOWAIT for async O_DIRECT IO") 893a1c97205a ("blk-mq: allow REQ_NOWAIT to return an error inline") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-08-15io_uring: fix manual setup of iov_iter for fixed buffersAleix Roca Nonell1-3/+1
Commit bd11b3a391e3 ("io_uring: don't use iov_iter_advance() for fixed buffers") introduced an optimization to avoid using the slow iov_iter_advance by manually populating the iov_iter iterator in some cases. However, the computation of the iterator count field was erroneous: The first bvec was always accounted for an extent of page size even if the bvec length was smaller. In consequence, some I/O operations on fixed buffers were unable to operate on the full extent of the buffer, consistently skipping some bytes at the end of it. Fixes: bd11b3a391e3 ("io_uring: don't use iov_iter_advance() for fixed buffers") Cc: stable@vger.kernel.org Signed-off-by: Aleix Roca Nonell <aleix.rocanonell@bsc.es> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2019-08-15misc: xilinx-sdfec: fix dependency and build errorRandy Dunlap1-0/+1
lib/devres.c, which implements devm_ioremap_resource(), is only built when CONFIG_HAS_IOMEM is set/enabled, so XILINX_SDFEC should depend on HAS_IOMEM. Fixes this build error (as seen on UML builds): ERROR: "devm_ioremap_resource" [drivers/misc/xilinx_sdfec.ko] undefined! Fixes: 76d83e1c3233 ("misc: xilinx-sdfec: add core driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Derek Kiernan <derek.kiernan@xilinx.com> Cc: Dragan Cvetic <dragan.cvetic@xilinx.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/f9004be5-9925-327b-3ec2-6506e46fe565@infradead.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15usb: add a hcd_uses_dma helperChristoph Hellwig5-11/+10
The USB buffer allocation code is the only place in the usb core (and in fact the whole kernel) that uses is_device_dma_capable, while the URB mapping code uses the uses_dma flag in struct usb_bus. Switch the buffer allocation to use the uses_dma flag used by the rest of the USB code, and create a helper in hcd.h that checks this flag as well as the CONFIG_HAS_DMA to simplify the caller a bit. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20190811080520.21712-3-hch@lst.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15usb: don't create dma pools for HCDs with a localmem_poolChristoph Hellwig1-3/+3
If the HCD provides a localmem pool we will never use the DMA pools, so don't create them. Fixes: b0310c2f09bb ("USB: use genalloc for USB HCs with local memory") Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20190811080520.21712-2-hch@lst.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15usb: chipidea: imx: fix EPROBE_DEFER support during driver probeAndré Draszik1-7/+12
If driver probe needs to be deferred, e.g. because ci_hdrc_add_device() isn't ready yet, this driver currently misbehaves badly: a) success is still reported to the driver core (meaning a 2nd probe attempt will never be done), leaving the driver in a dysfunctional state and the hardware unusable b) driver remove / shutdown OOPSes: [ 206.786916] Unable to handle kernel paging request at virtual address fffffdff [ 206.794148] pgd = 880b9f82 [ 206.796890] [fffffdff] *pgd=abf5e861, *pte=00000000, *ppte=00000000 [ 206.803179] Internal error: Oops: 37 [#1] PREEMPT SMP ARM [ 206.808581] Modules linked in: wl18xx evbug [ 206.813308] CPU: 1 PID: 1 Comm: systemd-shutdow Not tainted 4.19.35+gf345c93b4195 #1 [ 206.821053] Hardware name: Freescale i.MX7 Dual (Device Tree) [ 206.826813] PC is at ci_hdrc_remove_device+0x4/0x20 [ 206.831699] LR is at ci_hdrc_imx_remove+0x20/0xe8 [ 206.836407] pc : [<805cd4b0>] lr : [<805d62cc>] psr: 20000013 [ 206.842678] sp : a806be40 ip : 00000001 fp : 80adbd3c [ 206.847906] r10: 80b1b794 r9 : 80d5dfe0 r8 : a8192c44 [ 206.853136] r7 : 80db93a0 r6 : a8192c10 r5 : a8192c00 r4 : a93a4a00 [ 206.859668] r3 : 00000000 r2 : a8192ce4 r1 : ffffffff r0 : fffffdfb [ 206.866201] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 206.873341] Control: 10c5387d Table: a9e0c06a DAC: 00000051 [ 206.879092] Process systemd-shutdow (pid: 1, stack limit = 0xb271353c) [ 206.885624] Stack: (0xa806be40 to 0xa806c000) [ 206.889992] be40: a93a4a00 805d62cc a8192c1c a8170e10 a8192c10 8049a490 80d04d08 00000000 [ 206.898179] be60: 00000000 80d0da2c fee1dead 00000000 a806a000 00000058 00000000 80148b08 [ 206.906366] be80: 01234567 80148d8c a9858600 00000000 00000000 00000000 00000000 80d04d08 [ 206.914553] bea0: 00000000 00000000 a82741e0 a9858600 00000024 00000002 a9858608 00000005 [ 206.922740] bec0: 0000001e 8022c058 00000000 00000000 a806bf14 a9858600 00000000 a806befc [ 206.930927] bee0: a806bf78 00000000 7ee12c30 8022c18c a806bef8 a806befc 00000000 00000001 [ 206.939115] bf00: 00000000 00000024 a806bf14 00000005 7ee13b34 7ee12c68 00000004 7ee13f20 [ 206.947302] bf20: 00000010 7ee12c7c 00000005 7ee12d04 0000000a 76e7dc00 00000001 80d0f140 [ 206.955490] bf40: ab637880 a974de40 60000013 80d0f140 ab6378a0 80d04d08 a8080470 a9858600 [ 206.963677] bf60: a9858600 00000000 00000000 8022c24c 00000000 80144310 00000000 00000000 [ 206.971864] bf80: 80101204 80d04d08 00000000 80d04d08 00000000 00000000 00000003 00000058 [ 206.980051] bfa0: 80101204 80101000 00000000 00000000 fee1dead 28121969 01234567 00000000 [ 206.988237] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000 [ 206.996425] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6 60000030 fee1dead 00000000 00000000 [ 207.004622] [<805cd4b0>] (ci_hdrc_remove_device) from [<805d62cc>] (ci_hdrc_imx_remove+0x20/0xe8) [ 207.013509] [<805d62cc>] (ci_hdrc_imx_remove) from [<8049a490>] (device_shutdown+0x16c/0x218) [ 207.022050] [<8049a490>] (device_shutdown) from [<80148b08>] (kernel_restart+0xc/0x50) [ 207.029980] [<80148b08>] (kernel_restart) from [<80148d8c>] (sys_reboot+0xf4/0x1f0) [ 207.037648] [<80148d8c>] (sys_reboot) from [<80101000>] (ret_fast_syscall+0x0/0x54) [ 207.045308] Exception stack(0xa806bfa8 to 0xa806bff0) [ 207.050368] bfa0: 00000000 00000000 fee1dead 28121969 01234567 00000000 [ 207.058554] bfc0: 00000000 00000000 00000003 00000058 00000000 00000000 00000000 00000000 [ 207.066737] bfe0: 0049ffb0 7ee13d58 0048a84b 76f245a6 [ 207.071799] Code: ebffffa8 e3a00000 e8bd8010 e92d4010 (e5904004) [ 207.078021] ---[ end trace be47424e3fd46e9f ]--- [ 207.082647] Kernel panic - not syncing: Fatal exception [ 207.087894] ---[ end Kernel panic - not syncing: Fatal exception ]--- c) the error path in combination with driver removal causes imbalanced calls to the clk_*() and pm_()* APIs a) happens because the original intended return value is overwritten (with 0) by the return code of regulator_disable() in ci_hdrc_imx_probe()'s error path b) happens because ci_pdev is -EPROBE_DEFER, which causes ci_hdrc_remove_device() to OOPS Fix a) by being more careful in ci_hdrc_imx_probe()'s error path and not overwriting the real error code Fix b) by calling the respective cleanup functions during remove only when needed (when ci_pdev != NULL, i.e. when everything was initialised correctly). This also has the side effect of not causing imbalanced clk_*() and pm_*() API calls as part of the error code path. Fixes: 7c8e8909417e ("usb: chipidea: imx: add HSIC support") Signed-off-by: André Draszik <git@andred.net> Cc: stable <stable@vger.kernel.org> CC: Peter Chen <Peter.Chen@nxp.com> CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org> CC: Shawn Guo <shawnguo@kernel.org> CC: Sascha Hauer <s.hauer@pengutronix.de> CC: Pengutronix Kernel Team <kernel@pengutronix.de> CC: Fabio Estevam <festevam@gmail.com> CC: NXP Linux Team <linux-imx@nxp.com> CC: linux-usb@vger.kernel.org CC: linux-arm-kernel@lists.infradead.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20190810150758.17694-1-git@andred.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15usb: host: fotg2: restart hcd after port resetHans Ulli Kroll1-0/+4
On the Gemini SoC the FOTG2 stalls after port reset so restart the HCD after each port reset. Signed-off-by: Hans Ulli Kroll <ulli.kroll@googlemail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20190810150458.817-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15USB: CDC: fix sanity checks in CDC union parserOliver Neukum1-2/+2
A few checks checked for the size of the pointer to a structure instead of the structure itself. Copy & paste issue presumably. Fixes: e4c6fb7794982 ("usbnet: move the CDC parser into USB core") Cc: stable <stable@vger.kernel.org> Reported-by: syzbot+45a53506b65321c1fe91@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20190813093541.18889-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15usb: cdc-acm: make sure a refcount is taken early enoughOliver Neukum1-5/+7
destroy() will decrement the refcount on the interface, so that it needs to be taken so early that it never undercounts. Fixes: 7fb57a019f94e ("USB: cdc-acm: Fix potential deadlock (lockdep warning)") Cc: stable <stable@vger.kernel.org> Reported-and-tested-by: syzbot+1b2449b7b5dc240d107a@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20190808142119.7998-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-15USB: serial: option: add the BroadMobi BM818 cardBob Ham1-0/+2
Add a VID:PID for the BroadMobi BM818 M.2 card T: Bus=01 Lev=03 Prnt=40 Port=03 Cnt=01 Dev#= 44 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2020 ProdID=2060 Rev=00.00 S: Manufacturer=Qualcomm, Incorporated S: Product=Qualcomm CDMA Technologies MSM C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) Signed-off-by: Bob Ham <bob.ham@puri.sm> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca> Cc: stable <stable@vger.kernel.org> [ johan: use USB_DEVICE_INTERFACE_CLASS() ] Signed-off-by: Johan Hovold <johan@kernel.org>
2019-08-15USB: serial: option: Add Motorola modem UARTsTony Lindgren1-0/+5
On Motorola Mapphone devices such as Droid 4 there are five USB ports that do not use the same layout as Gobi 1K/2K/etc devices listed in qcserial.c. So we should use qcaux.c or option.c as noted by Dan Williams <dan.j.williams@intel.com>. As the Motorola USB serial ports have an interrupt endpoint as shown with lsusb -v, we should use option.c instead of qcaux.c as pointed out by Johan Hovold <johan@kernel.org>. The ff/ff/ff interfaces seem to always be UARTs on Motorola devices. For the other interfaces, class 0x0a (CDC Data) should not in general be added as they are typically part of a multi-interface function as noted earlier by Bjørn Mork <bjorn@mork.no>. However, looking at the Motorola mapphone kernel code, the mdm6600 0x0a class is only used for flashing the modem firmware, and there are no other interfaces. So I've added that too with more details below as it works just fine. The ttyUSB ports on Droid 4 are: ttyUSB0 DIAG, CQDM-capable ttyUSB1 MUX or NMEA, no response ttyUSB2 MUX or NMEA, no response ttyUSB3 TCMD ttyUSB4 AT-capable The ttyUSB0 is detected as QCDM capable by ModemManager. I think it's only used for debugging with ModemManager --debug for sending custom AT commands though. ModemManager already can manage data connection using the USB QMI ports that are already handled by the qmi_wwan.c driver. To enable the MUX or NMEA ports, it seems that something needs to be done additionally to enable them, maybe via the DIAG or TCMD port. It might be just a NVRAM setting somewhere, but I have no idea what NVRAM settings may need changing for that. The TCMD port seems to be a Motorola custom protocol for testing the modem and to configure it's NVRAM and seems to work just fine based on a quick test with a minimal tcmdrw tool I wrote. The voice modem AT-capable port seems to provide only partial support, and no PM support compared to the TS 27.010 based UART wired directly to the modem. The UARTs added with this change are the same product IDs as the Motorola Mapphone Android Linux kernel mdm6600_id_table. I don't have any mdm9600 based devices, so I have only tested these on mdm6600 based droid 4. Then for the class 0x0a (CDC Data) mode, the Motorola Mapphone Android Linux kernel driver moto_flashqsc.c just seems to change the port->bulk_out_size to 8K from the default. And is only used for flashing the modem firmware it seems. I've verified that flashing the modem with signed firmware works just fine with the option driver after manually toggling the GPIO pins, so I've added droid 4 modem flashing mode to the option driver. I've not added the other devices listed in moto_flashqsc.c in case they really need different port->bulk_out_size. Those can be added as they get tested to work for flashing the modem. After this patch the output of /sys/kernel/debug/usb/devices has the following for normal 22b8:2a70 mode including the related qmi_wwan interfaces: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=22b8 ProdID=2a70 Rev= 0.00 S: Manufacturer=Motorola, Incorporated S: Product=Flash MZ600 C:* #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=86(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=88(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan E: Ad=89(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=8a(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan E: Ad=8b(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=8c(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=08(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fb Prot=ff Driver=qmi_wwan E: Ad=8d(I) Atr=03(Int.) MxPS= 64 Ivl=5ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms In 22b8:900e "qc_dload" mode the device shows up as: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=22b8 ProdID=900e Rev= 0.00 S: Manufacturer=Motorola, Incorporated S: Product=Flash MZ600 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms And in 22b8:4281 "ram_downloader" mode the device shows up as: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=22b8 ProdID=4281 Rev= 0.00 S: Manufacturer=Motorola, Incorporated S: Product=Flash MZ600 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=fc Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Cc: Bjørn Mork <bjorn@mork.no> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Lars Melin <larsm17@gmail.com> Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Scott <hashcode0f@gmail.com> Cc: NeKit <nekit1000@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Tested-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2019-08-15MAINTAINERS, x86/CPU: Tony Luck will maintain asm/intel-family.hTony Luck1-0/+7
There are a few different subsystems in the kernel that depend on model specific behaviour (perf, EDAC, power, ...). Easier for just one person to have the task to get new model numbers included instead of having these groups trip over each other to do it. [ bp: s/Cpu/CPU/ and add x86@kernel.org so that it gets CCed too as FYI. ] Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Dave Hansen <dave.hansen@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190814234030.30817-1-tony.luck@intel.com
2019-08-15drm/nouveau: Only recalculate PBN/VCPI on mode/connector changesLyude Paul1-9/+13
I -thought- I had fixed this entirely, but it looks like that I didn't test this thoroughly enough as we apparently still make one big mistake with nv50_msto_atomic_check() - we don't handle the following scenario: * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4 which is attached to encoder #1. enabled=y active=n * CRTC #1 is changed from DP-4 to DP-5, causing: * DP-4 crtc=#1→NULL (VCPI n→0) * DP-5 crtc=NULL→#1 * CRTC #1 steals encoder #1 back from DP-4 and gives it to DP-5 * CRTC #1 maintains the same mode as before, just with a different connector * mode_changed=n connectors_changed=y (we _SHOULD_ do VCPI 0→n here, but don't) Once the above scenario is repeated once, we'll attempt freeing VCPI from the connector that we didn't allocate due to the connectors changing, but the mode staying the same. Sigh. Since nv50_msto_atomic_check() has broken a few times now, let's rethink things a bit to be more careful: limit both VCPI/PBN allocations to mode_changed || connectors_changed, since neither VCPI or PBN should ever need to change outside of routing and mode changes. Changes since v1: * Fix accidental reversal of clock and bpp arguments in drm_dp_calc_pbn_mode() - William Lewis Signed-off-by: Lyude Paul <lyude@redhat.com> Reported-by: Bohdan Milar <bmilar@redhat.com> Tested-by: Bohdan Milar <bmilar@redhat.com> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") References: 412e85b60531 ("drm/nouveau: Only release VCPI slots on mode changes") Cc: Lyude Paul <lyude@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Juston Li <juston.li@intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Karol Herbst <karolherbst@gmail.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <stable@vger.kernel.org> # v5.1+ Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190809005307.18391-1-lyude@redhat.com
2019-08-15drm/ast: Fixed reboot test may cause system hangedY.C. Chen3-3/+6
There is another thread still access standard VGA I/O while loading drm driver. Disable standard VGA I/O decode to avoid this issue. Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com> Reviewed-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/1523410059-18415-1-git-send-email-yc_chen@aspeedtech.com
2019-08-15of: irq: fix a trivial typo in a doc commentLubomir Rintel1-1/+1
Diverged from what the code does with commit 530210c7814e ("of/irq: Replace of_irq with of_phandle_args"). Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Rob Herring <robh@kernel.org>
2019-08-15dt-bindings: pinctrl: stm32: Fix 'st,syscfg' schemaRob Herring1-1/+2
The proper way to add additional contraints to an existing json-schema is using 'allOf' to reference the base schema. Using just '$ref' doesn't work. Fix this for the 'st,syscfg' property. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: linux-gpio@vger.kernel.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-arm-kernel@lists.infradead.org Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
2019-08-14drm/scheduler: use job count instead of peekChristian König1-2/+2
The spsc_queue_peek function is accessing queue->head which belongs to the consumer thread and shouldn't be accessed by the producer This is fixing a rare race condition when destroying entities. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Monk.liu@amd.com Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-19 21:51:31 +0100