- 20 Nov, 2019 40 commits
-
-
Gustavo A. R. Silva authored
[ Upstream commit 17a0a1e5 ] Check return value of devm_pci_remap_iospace(). Addresses-Coverity-ID: 1471965 ("Unchecked return value") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by:
Honghui Zhang <honghui.zhang@mediatek.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jia-Ju Bai authored
[ Upstream commit 0020f5c8 ] The driver may sleep with holding a spinlock. The function call paths (from bottom to top) in Linux-4.17 are: [FUNC] usleep_range drivers/net/ethernet/socionext/sni_ave.c, 892: usleep_range in ave_rxfifo_reset drivers/net/ethernet/socionext/sni_ave.c, 932: ave_rxfifo_reset in ave_irq_handler [FUNC] usleep_range drivers/net/ethernet/socionext/sni_ave.c, 888: usleep_range in ave_rxfifo_reset drivers/net/ethernet/socionext/sni_ave.c, 932: ave_rxfifo_reset in ave_irq_handler To fix these bugs, usleep_range() is replaced with udelay(). These bugs are found by my static analysis tool DSAC. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sinan Kaya authored
[ Upstream commit 1ad61b61 ] If _OSC execution fails today for platforms without an _OSC entry, code is printing a misleading message saying disabling ASPM as follows: acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM We need to ensure that platform supports ASPM to begin with. Reported-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
Sinan Kaya <okaya@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Javier Martinez Canillas authored
[ Upstream commit b7a41762 ] The driver registers the v4l2 subdevice before attempting to power on the chip and checking its ID. This means that a media device driver that it's waiting for this subdevice to be bound, will prematurely expose its media device node to userspace because if something goes wrong the media entity will be cleaned up again on the ov2680 probe function. This also simplifies the probe function error path since no initialization is made before attempting to enable the resources or checking the chip ID. Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Koji Matsuoka authored
[ Upstream commit 9b2798d5 ] YCbCr planar formats can have different pitch values for the luma and chroma planes. This isn't taken into account in the driver. Fix it. Based on a BSP patch from Koji Matsuoka <koji.matsuoka.xm@renesas.com>. Fixes: 7863ac50 ("drm: rcar-du: Add tri-planar memory formats support") [Updated documentation of the struct vsp1_du_atomic_config pitch field] Signed-off-by:
Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
[ Upstream commit 5eea860a ] All source files of the vsp1 driver are licensed under the GPLv2+ except for vsp1_regs.h which is licensed under GPLv2. This is caused by a bad copy&paste that dates back from the initial version of the driver. Fix it. Acked-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Signed-off-by:
-
Julian Wiedmann authored
[ Upstream commit 4d19db77 ] Calling napi_schedule() from process context does not ensure that the NET_RX softirq is run in a timely fashion. So trigger it manually. This is no big issue with current code. A call to ndo_open() is usually followed by a ndo_set_rx_mode() call, and for qeth this contains a spin_unlock_bh(). Except for OSN, where qeth_l2_set_rx_mode() bails out early. Nevertheless it's best to not depend on this behaviour, and just fix the issue at its source like all other drivers do. For instance see commit 83a0c6e5 ("i40e: Invoke softirqs after napi_reschedule"). Fixes: a1c3ed4c ("qeth: NAPI support for l2 and l3 discipline") Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
[ Upstream commit 121ca39a ] When setting up, qeth installs its IRQ handler on the ccw devices. But the IRQ handler is not cleared on removal - so even after qeth yields control of the ccw devices, spurious interrupts would still be presented to us. Make (de-)installation of the IRQ handler part of the ccw channel setup/removal helpers, and while at it also add the appropriate locking. Shift around qeth_setup_channel() to avoid a forward declaration for qeth_irq(). Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 461cf036 ] We tried to revert commit d9c52fd1 ("ath9k: fix tx99 with monitor mode interface") but accidentally missed part of the locking change. The lock has to be held earlier so that we're holding it when we do "sc->tx99_vif = vif;" and also there in the current code there is a stray unlock before we have taken the lock. Fixes: 6df0580b ("ath9k: add back support for using active monitor interfaces for tx99") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Florian Westphal authored
[ Upstream commit fa5950e4 ] None of these spots really needs to crash the kernel. In one two cases we can jsut report error to userspace, in the other cases we can just use WARN_ON (and leak memory instead). Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 86b62e5c ] lpss_iosf_enter_d3_state() checks if all hw-blocks using the DMA controllers are in d3 before powering down the DMA controllers. But on devices, where the I2C bus connected to the PMIC is shared by the PUNIT, the controller for that bus will never reach d3 since it has an effectively empty _PS3 method. Instead it appears to automatically power-down during S0i3 and we never see it as being in d3. This causes the DMA controllers to never be powered-down on these devices, causing them to never reach S0i3. This commit uses the ACPI _SEM method to detect if an I2C bus is shared with the PUNIT and if it is, it removes it from the mask of devices which lpss_iosf_enter_d3_state() checks for. This fixes these devices never reaching any S0ix states. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 501500e6 ] dtc has new checks for I2C buses. Fix the warnings in unit-addresses. arch/arm64/boot/dts/rockchip/rk3399-puma-haikou.dtb: Warning (i2c_bus_reg): /i2c@ff3d0000/codec@0a: I2C bus unit address format error, expected "a" Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-rockchip@lists.infradead.org Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 131c3eb4 ] dtc has new checks for SPI buses. The rk3036 dts file has a node named spi' which causes false positive warnings. As the node is a pinctrl child node, change the node name to be 'spi-pins' to fix the warnings. arch/arm/boot/dts/rk3036-evb.dtb: Warning (spi_bus_bridge): /pinctrl/spi: incorrect #address-cells for SPI bus arch/arm/boot/dts/rk3036-kylin.dtb: Warning (spi_bus_bridge): /pinctrl/spi: incorrect #address-cells for SPI bus arch/arm/boot/dts/rk3036-evb.dtb: Warning (spi_bus_bridge): /pinctrl/spi: incorrect #size-cells for SPI bus arch/arm/boot/dts/rk3036-kylin.dtb: Warning (spi_bus_bridge): /pinctrl/spi: incorrect #size-cells for SPI bus Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-rockchip@lists.infradead.org Signed-off-by:
-
Vivek Gautam authored
[ Upstream commit eebcc196 ] Error paths in ufshcd_init() ufshcd_hba_exit() killed clk_scaling workqueue when the workqueue is actually created quite late in ufshcd_init(). So, we end up getting NULL pointer dereference in such error paths. Fix this by moving clk_scaling initialization and kill codes to two separate methods, and call them at required places. Fixes: 401f1e44 ("scsi: ufs: don't suspend clock scaling during clock gating") Signed-off-by:
Vivek Gautam <vivek.gautam@codeaurora.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Subhash Jadavani <subhashj@codeaurora.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Evan Green <evgreen@chromium.org> Cc: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by:
Evan Green <evgreen@chromium.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Haishuang Yan authored
[ Upstream commit b0350d51 ] gre_parse_header stops parsing when csum_err is encountered, which means tpi->key is undefined and ip_tunnel_lookup will return NULL improperly. This patch introduce a NULL pointer as csum_err parameter. Even when csum_err is encountered, it won't return error and continue parsing gre header as expected. Fixes: 9f57c67c ("gre: Remove support for sharing GRE protocol hook.") Reported-by:
Jiri Benc <jbenc@redhat.com> Signed-off-by:
Haishuang Yan <yanhaishuang@cmss.chinamobile.com> Signed-off-by:
-
Bernd Edlinger authored
[ Upstream commit a75e78f2 ] The terminating NUL byte is only there because the buffer is allocated with kzalloc(PAGE_SIZE, GFP_KERNEL), but since the range-check is off-by-one, and PAGE_SIZE==PATH_MAX, the returned string may not be zero-terminated if it is exactly PATH_MAX characters long. Furthermore also the initial loop may theoretically exceed PATH_MAX and cause a fault. Signed-off-by:
Bernd Edlinger <bernd.edlinger@hotmail.de> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Banajit Goswami authored
[ Upstream commit bdae566d ] During component_bind_all(), if bind() fails for any particular component associated with a master, unbind() should be called for all previous components in that master's match array, whose bind() might have completed successfully. As per the current logic, if bind() fails for the component at position 'n' in the master's match array, it would start calling unbind() from component in 'n'th position itself and work backwards, and will always skip calling unbind() for component in 0th position in the master's match array. Fix this by updating the loop condition, and the logic to refer to the components in master's match array, so that unbind() is called for all components starting from 'n-1'st position in the array, until (and including) component in 0th position. Signed-off-by:
Banajit Goswami <bgoswami@codeaurora.org> Signed-off-by:
-
Tomasz Figa authored
[ Upstream commit cb90a2c6 ] Since the max8998 MFD driver supports instantiation by DT, platform data retrieval is handled in MFD probe and cell drivers should get use the pdata field of max8998_dev struct to obtain them. Fixes: ee999fb3 ("mfd: max8998: Add support for Device Tree") Signed-off-by:
Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by:
Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Claudiu Beznea authored
[ Upstream commit 9f1e4477 ] There should be only one instance of struct shdwc in the system. This is referenced through at91_shdwc. Return in probe if at91_shdwc is already allocated. Signed-off-by:
Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 54baff8d ] If kstrtoul() fails then we print "charge_full" when it's uninitialized. The debug printk doesn't add anything so I deleted it and cleaned these two functions up a bit. Signed-off-by:
-
Rob Herring authored
[ Upstream commit 68ecb5c1 ] dtc has new checks for SPI buses. The meson dts files have a node named spi' which causes false positive warnings. As the node is a pinctrl child node, change the node name to be 'spi-pins' to fix the warnings. arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dtb: Warning (spi_bus_bridge): /soc/periphs@c8834000/pinctrl@4b0/spi: incorrect #address-cells for SPI bus Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: linux-amlogic@lists.infradead.org Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Paolo Valente authored
[ Upstream commit c8765de0 ] To reduce latency for interactive and soft real-time applications, bfq privileges the bfq_queues containing the I/O of these applications. These privileged queues, referred-to as weight-raised queues, get a much higher share of the device throughput w.r.t. non-privileged queues. To preserve this higher share, the I/O of any non-weight-raised queue must be plugged whenever a sync weight-raised queue, while being served, remains temporarily empty. To attain this goal, bfq simply plugs any I/O (from any queue), if a sync weight-raised queue remains empty while in service. Unfortunately, this plugging typically lowers throughput with random I/O, on devices with internal queueing (because it reduces the filling level of the internal queues of the device). This commit addresses this issue by restricting the cases where plugging is performed: if a sync weight-raised queue remains empty while in service, then I/O plugging is performed only if some of the active bfq_queues are *not* weight-raised (which is actually the only circumstance where plugging is needed to preserve the higher share of the throughput of weight-raised queues). This restriction proved able to boost throughput in really many use cases needing only maximum throughput. Signed-off-by:
Paolo Valente <paolo.valente@linaro.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Paolo Valente authored
[ Upstream commit d0edc247 ] The Achilles' heel of BFQ is its failing to reach a high throughput with sync random I/O on flash storage with internal queueing, in case the processes doing I/O have differentiated weights. The cause of this failure is as follows. If at least two processes do sync I/O, and have a different weight from each other, then BFQ plugs I/O dispatching every time one of these processes, while it is being served, remains temporarily without pending I/O requests. This plugging is necessary to guarantee that every process enjoys a bandwidth proportional to its weight; but it empties the internal queue(s) of the drive. And this kills throughput with random I/O. So, if some processes have differentiated weights and do both sync and random I/O, the end result is a throughput collapse. This commit tries to counter this problem by injecting the service of other processes, in a controlled way, while the process in service happens to have no I/O. This injection is performed only if the medium is non rotational and performs internal queueing, and the process in service does random I/O (service injection might be beneficial for sequential I/O too, we'll work on that). As an example of the benefits of this commit, on a PLEXTOR PX-256M5S SSD, and with five processes having differentiated weights and doing sync random 4KB I/O, this commit makes the throughput with bfq grow by 400%, from 25 to 100MB/s. This higher throughput is 10MB/s lower than that reached with none. As some less random I/O is added to the mix, the throughput becomes equal to or higher than that with none. This commit is a very first attempt to recover throughput without losing control, and certainly has many limitations. One is, e.g., that the processes whose service is injected are not chosen so as to distribute the extra bandwidth they receive in accordance to their weights. Thus there might be loss of weighted fairness in some cases. Anyway, this loss concerns extra service, which would not have been received at all without this commit. Other limitations and issues will probably show up with usage. Signed-off-by:
-
Hari Vyas authored
[ Upstream commit e4ba15de ] The bad_mode() handler is called if we encounter an uunknown exception, with the expectation that the subsequent call to panic() will halt the system. Unfortunately, if the exception calling bad_mode() is taken from EL0, then the call to die() can end up killing the current user task and calling schedule() instead of falling through to panic(). Remove the die() call altogether, since we really want to bring down the machine in this "impossible" case. Signed-off-by:
Hari Vyas <hari.vyas@broadcom.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Ganesh Goudar authored
[ Upstream commit 0dc235af ] Do not put host-endian 0 or 1 into big endian feild. Reported-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by:
-
Sherry Yang authored
[ Upstream commit 44b73962 ] When a process dies, failed reply is sent to the sender of any transaction queued on a dead thread's todo list. The sender asserts that the received failed reply corresponds to the head of the transaction stack. This assert can fail if the dead thread is allowed to send outgoing transactions when there is already a transaction on its todo list, because this new transaction can end up on the transaction stack of the original sender. The following steps illustrate how this assertion can fail. 1. Thread1 sends txn19 to Thread2 (T1->transaction_stack=txn19, T2->todo+=txn19) 2. Without processing todo list, Thread2 sends txn20 to Thread1 (T1->todo+=txn20, T2->transaction_stack=txn20) 3. T1 processes txn20 on its todo list (T1->transaction_stack=txn20->txn19, T1->todo=<empty>) 4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but T1->transaction_stack points to txn20 -- assertion failes Step 2. is the incorrect behavior. When there is a transaction on a thread's todo list, this thread should not be able to send any outgoing synchronous transactions. Only the head of the todo list needs to be checked because only threads that are waiting for proc work can directly receive work from another thread, and no work is allowed to be queued on such a thread without waking up the thread. This patch also enforces that a thread is not waiting for proc work when a work is directly enqueued to its todo list. Acked-by:
Arve Hjønnevåg <arve@android.com> Signed-off-by:
Sherry Yang <sherryy@android.com> Reviewed-by:
Martijn Coenen <maco@android.com> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 57a83c52 ] dtc has new checks for I2C buses. The sun9i-a80 dts file has a node named 'i2c' which causes a false positive warning. As the node is a RSB bus, correct the node name to be 'rsb' to fix the warnings. arch/arm/boot/dts/sun9i-a80-cubieboard4.dtb: Warning (i2c_bus_reg): /soc/i2c@8003400/codec@e89:reg: I2C address must be less than 10-bits, got "0xe89" arch/arm/boot/dts/sun9i-a80-cubieboard4.dtb: Warning (i2c_bus_reg): /soc/i2c@8003400/pmic@745:reg: I2C address must be less than 10-bits, got "0x745" arch/arm/boot/dts/sun9i-a80-optimus.dtb: Warning (i2c_bus_reg): /soc/i2c@8003400/codec@e89:reg: I2C address must be less than 10-bits, got "0xe89" arch/arm/boot/dts/sun9i-a80-optimus.dtb: Warning (i2c_bus_reg): /soc/i2c@8003400/pmic@745:reg: I2C address must be less than 10-bits, got "0x745" Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Ludovic Desroches authored
[ Upstream commit 0c3dfa17 ] Sharing the same irqchip with multiple gpiochips is not a good practice. For instance, when installing hooks, we change the state of the irqchip. The initial state of the irqchip for the second gpiochip to register is then disrupted. Signed-off-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 0729b4af ] dtc has new checks for I2C buses. Fix the warnings in unit-addresses. arch/arm/boot/dts/sun8i-a23-gt90h-v4.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2ac00/touchscreen@0: I2C bus unit address format error, expected "40" arch/arm/boot/dts/sun8i-a23-inet86dz.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2ac00/touchscreen@0: I2C bus unit address format error, expected "40" arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2ac00/touchscreen@0: I2C bus unit address format error, expected "40" arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2ac00/touchscreen@0: I2C bus unit address format error, expected "40" arch/arm/boot/dts/sun8i-a33-ga10h-v1.1.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2ac00/touchscreen@0: I2C bus unit address format error, expected "40" arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2ac00/touchscreen@0: missing or empty reg property arch/arm/boot/dts/sun8i-a33-ippo-q8h-v1.2.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2ac00/touchscreen@0: missing or empty reg property arch/arm/boot/dts/sun8i-a33-q8-tablet.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2ac00/touchscreen@0: missing or empty reg property arch/arm/boot/dts/sun5i-a13-utoo-p66.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2b000/touchscreen: I2C bus unit address format error, expected "40" arch/arm/boot/dts/sun5i-a13-difrnce-dit4350.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2b000/touchscreen: missing or empty reg property arch/arm/boot/dts/sun5i-a13-empire-electronix-m712.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2b000/touchscreen: missing or empty reg property arch/arm/boot/dts/sun5i-a13-inet-98v-rev2.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2b000/touchscreen: missing or empty reg property arch/arm/boot/dts/sun5i-a13-q8-tablet.dtb: Warning (i2c_bus_reg): /soc@1c00000/i2c@1c2b000/touchscreen: missing or empty reg property Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Dinh Nguyen authored
[ Upstream commit cbbc488e ] dtc has new checks for I2C buses. Fix the warnings in unit-addresses. arch/arm/boot/dts/socfpga_cyclone5_de0_sockit.dtb: Warning (i2c_bus_reg): /soc/i2c@ffc04000/adxl345@0: I2C bus unit address format error, expected "53" Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Signed-off-by:
-
Alan Modra authored
[ Upstream commit 56d20861 ] Call Frame Information is used by gdb for back-traces and inserting breakpoints on function return for the "finish" command. This failed when inside __kernel_clock_gettime. More concerning than difficulty debugging is that CFI is also used by stack frame unwinding code to implement exceptions. If you have an app that needs to handle asynchronous exceptions for some reason, and you are unlucky enough to get one inside the VDSO time functions, your app will crash. What's wrong: There is control flow in __kernel_clock_gettime that reaches label 99 without saving lr in r12. CFI info however is interpreted by the unwinder without reference to control flow: It's a simple matter of "Execute all the CFI opcodes up to the current address". That means the unwinder thinks r12 contains the return address at label 99. Disabuse it of that notion by resetting CFI for the return address at label 99. Note that the ".cfi_restore lr" could have gone anywhere from the "mtlr r12" a few instructions earlier to the instruction at label 99. I put the CFI as late as possible, because in general that's best practice (and if possible grouped with other CFI in order to reduce the number of CFI opcodes executed when unwinding). Using r12 as the return address is perfectly fine after the "mtlr r12" since r12 on that code path still contains the return address. __get_datapage also has a CFI error. That function temporarily saves lr in r0, and reflects that fact with ".cfi_register lr,r0". A later use of r0 means the CFI at that point isn't correct, as r0 no longer contains the return address. Fix that too. Signed-off-by:
Alan Modra <amodra@gmail.com> Tested-by:
Reza Arbab <arbab@linux.ibm.com> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 1426d40e ] dtc has new checks for I2C buses. The ASpeed dts files have a node named 'i2c' which causes a false positive warning. As the node is a 'simple-bus', correct the node name to be 'bus' to fix the warnings. arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus arch/arm/boot/dts/aspeed-bmc-opp-romulus.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus arch/arm/boot/dts/aspeed-ast2500-evb.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus arch/arm/boot/dts/aspeed-bmc-arm-centriq2400-rep.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus arch/arm/boot/dts/aspeed-bmc-intel-s2600wf.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus arch/arm/boot/dts/aspeed-bmc-opp-zaius.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus arch/arm/boot/dts/aspeed-bmc-portwell-neptune.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus arch/arm/boot/dts/aspeed-bmc-quanta-q71l.dtb: Warning (i2c_bus_bridge): /ahb/apb/i2c@1e78a000: incorrect #size-cells for I2C bus Cc: Joel Stanley <joel@jms.id.au> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: linux-aspeed@lists.ozlabs.org Signed-off-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Rob Herring authored
[ Upstream commit ab0b47d2 ] dtc has new checks for SPI buses. Fix the warnings in node names. arch/arm/boot/dts/bcm53340-ubnt-unifi-switch8.dtb: Warning (spi_bus_bridge): /axi@18000000/qspi@27200: node name for SPI buses should be 'spi' arch/arm/boot/dts/bcm958525er.dtb: Warning (spi_bus_bridge): /axi/qspi@27200: node name for SPI buses should be 'spi' arch/arm/boot/dts/bcm958525xmc.dtb: Warning (spi_bus_bridge): /axi/qspi@27200: node name for SPI buses should be 'spi' arch/arm/boot/dts/bcm958622hr.dtb: Warning (spi_bus_bridge): /axi/qspi@27200: node name for SPI buses should be 'spi' arch/arm/boot/dts/bcm958625hr.dtb: Warning (spi_bus_bridge): /axi/qspi@27200: node name for SPI buses should be 'spi' arch/arm/boot/dts/bcm988312hr.dtb: Warning (spi_bus_bridge): /axi/qspi@27200: node name for SPI buses should be 'spi' Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Jon Mason <jonmason@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 7cdbe45d ] dtc has new checks for I2C and SPI buses. Fix the warnings in node names and unit-addresses. arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dtb: Warning (i2c_bus_reg): /hsls/i2c@e0000/pcf8574@20: I2C bus unit address format error, expected "27" arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dtb: Warning (i2c_bus_reg): /hsls/i2c@e0000/pcf8574@20: I2C bus unit address format error, expected "27" arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dtb: Warning (spi_bus_bridge): /hsls/ssp@180000: node name for SPI buses should be 'spi' arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dtb: Warning (spi_bus_bridge): /hsls/ssp@190000: node name for SPI buses should be 'spi' Cc: Ray Jui <rjui@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Jon Mason <jonmason@broadcom.com> Cc: bcm-kernel-feedback-list@broadcom.com Signed-off-by:
Scott Branden <sbranden@broadcom.com> Signed-off-by:
-
Lina Iyer authored
[ Upstream commit 09e97b6c ] The wait_for_compl register ensures the request sequence is maintained when sending requests from the TCS. Clear the register after sending active request and during invalidate of the sleep and wake TCS. Reported-by:
Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Signed-off-by:
Lina Iyer <ilina@codeaurora.org> Signed-off-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
-
Niklas Cassel authored
[ Upstream commit 4fadb265 ] 'adev->name' is used as a NUL-terminated string, but using strncpy() with the length equal to the buffer size may result in lack of the termination: In function 'apr_add_device', inlined from 'of_register_apr_devices' at drivers//soc/qcom/apr.c:264:7, inlined from 'apr_probe' at drivers//soc/qcom/apr.c:290:2: drivers//soc/qcom/apr.c:222:3: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation] strncpy(adev->name, np->name, APR_NAME_SIZE); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This changes it to use the safer strscpy() instead. Signed-off-by:
Niklas Cassel <niklas.cassel@linaro.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Niklas Cassel authored
[ Upstream commit 4c96ed17 ] 'chinfo.name' is used as a NUL-terminated string, but using strncpy() with the length equal to the buffer size may result in lack of the termination: drivers//soc/qcom/wcnss_ctrl.c: In function 'qcom_wcnss_open_channel': drivers//soc/qcom/wcnss_ctrl.c:284:2: warning: 'strncpy' specified bound 32 equals destination size [-Wstringop-truncation] strncpy(chinfo.name, name, sizeof(chinfo.name)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This changes it to use the safer strscpy() instead. Signed-off-by:
-
Douglas Anderson authored
[ Upstream commit 867d4aa7 ] The geni_se_clk_freq_match() has some strange semantics. Specifically it is defined with two modes: 1. It can find a clock that's an exact multiple of the requested rate 2. It can find a non-exact match but it can't handle multiples then ...but callers should always be able to handle a clock that is a multiple of the requested clock so mode #2 doesn't really make sense. Let's change the semantics so that the non-exact match can also accept multiples and then change the code to handle that. The only caller of this code is the unlanded SPI driver [1] which currently passes "exact = True", thus it should be safe to change the semantics in this way. ...and, in fact, the SPI driver should likely be modified to pass "exact = False" (with the new semantics) since that will allow it to work with SPI devices that request a clock rate that doesn't exactly match a rate we can make. [1] https://lkml.kernel.org/r/1535107336-2214-1-git-send-email-dkota@codeaurora.org Fixes: eddac5af ("soc: qcom: Add GENI based QUP Wrapper driver") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
-
Douglas Anderson authored
[ Upstream commit e11bbced ] The function clk_round_rate() is defined to return a "long", not an "unsigned long". That's because it might return a negative error code. Change the call in geni_se_clk_tbl_get() to check for errors. While we're at it, get rid of a useless init of "freq". NOTE: overall the idea that we should iterate over clk_round_rate() to try to reconstruct a table already present in the clock driver is questionable. Specifically: - This method relies on "clk_round_rate()" rounding up. - This method only works if the table is sorted and has no duplicates. ...this patch doesn't try to fix those problems, it just makes the error handling more correct. Fixes: eddac5af ("soc: qcom: Add GENI based QUP Wrapper driver") Signed-off-by:
-
Christian Lamparter authored
[ Upstream commit bd73a3dd ] while compiling an ipq4019 target, dtc will complain: regulator@b089000 unit address format error, expected "2089000" The saw0 regulator reg value seems to be copied and pasted from qcom-ipq8064.dtsi. This patch fixes the reg value to match that of the unit address which in turn silences the warning. (There is no driver for qcom,saw2 right now. So this went unnoticed) Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
John Crispin <john@phrozen.org> Signed-off-by:
-
