summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-03-25remoteproc/omap: Add a sanity check for DSP boot address alignmentSuman Anna
The DSP remote processors on OMAP SoCs require a boot register to be programmed with a boot address, and this boot address needs to be on a 1KB boundary. The current code is simply masking the boot address appropriately without performing any sanity checks before releasing the resets. An unaligned boot address results in an undefined execution behavior and can result in various bus errors like MMU Faults or L3 NoC errors. Such errors are hard to debug and can be easily avoided by adding a sanity check for the alignment before booting a DSP remote processor. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Andrew F. Davis <afd@ti.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324110035.29907-4-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc/omap: Add device tree supportSuman Anna
OMAP4+ SoCs support device tree boot only. The OMAP remoteproc driver is enhanced to support remoteproc devices created through Device Tree, support for legacy platform devices has been deprecated. The current DT support handles the IPU and DSP processor subsystems on OMAP4 and OMAP5 SoCs. The OMAP remoteproc driver relies on the ti-sysc, reset, and syscon layers for performing clock, reset and boot vector management (DSP remoteprocs only) of the devices, but some of these are limited only to the machine-specific layers in arch/arm. The dependency against control module API for boot vector management of the DSP remoteprocs has now been removed with added logic to parse the boot register from the DT node and program it appropriately directly within the driver. The OMAP remoteproc driver expects the firmware names to be provided via device tree entries (firmware-name.) These are used to load the proper firmware during boot of the remote processor. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Suman Anna <s-anna@ti.com> [t-kristo@ti.com: converted to use ti-sysc framework] Signed-off-by: Tero Kristo <t-kristo@ti.com> Reviewed-by: Andrew F. Davis <afd@ti.com> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324110035.29907-3-t-kristo@ti.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: qcom: Introduce panic handler for PAS and ADSPBjorn Andersson
Make the PAS and ADSP/CDSP remoteproc drivers implement the panic handler that will invoke a stop to prepare the remoteprocs for post mortem debugging. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324052904.738594-5-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: qcom: q6v5: Add common panic handlerBjorn Andersson
Add a common panic handler that invokes a stop request and sleep enough to let the remoteproc flush it's caches etc in order to aid post mortem debugging. For now a hard coded 200ms is returned to the remoteproc core, this value is taken from the downstream kernel. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324052904.738594-4-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Introduce "panic" callback in opsBjorn Andersson
Introduce generic support for handling kernel panics in remoteproc drivers, in order to allow operations needed for aiding in post mortem system debugging, such as flushing caches etc. The function can return a number of milliseconds needed by the remote to "settle" and the core will wait the longest returned duration before returning from the panic handler. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324052904.738594-3-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Traverse rproc_list under RCU read lockBjorn Andersson
In order to be able to traverse the mostly read-only rproc_list without locking during panic migrate traversal to be done under rcu_read_lock(). Mutual exclusion for modifications of the list continues to be handled by the rproc_list_mutex and a synchronization point is added before releasing objects that are popped from the list. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200324052904.738594-2-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Fix NULL pointer dereference in rproc_virtio_notifyNikita Shubin
Undefined rproc_ops .kick method in remoteproc driver will result in "Unable to handle kernel NULL pointer dereference" in rproc_virtio_notify, after firmware loading if: 1) .kick method wasn't defined in driver 2) resource_table exists in firmware and has "Virtio device entry" defined Let's refuse to register an rproc-induced virtio device if no kick method was defined for rproc. [ 13.180049][ T415] 8<--- cut here --- [ 13.190558][ T415] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 13.212544][ T415] pgd = (ptrval) [ 13.217052][ T415] [00000000] *pgd=00000000 [ 13.224692][ T415] Internal error: Oops: 80000005 [#1] PREEMPT SMP ARM [ 13.231318][ T415] Modules linked in: rpmsg_char imx_rproc virtio_rpmsg_bus rpmsg_core [last unloaded: imx_rproc] [ 13.241687][ T415] CPU: 0 PID: 415 Comm: unload-load.sh Not tainted 5.5.2-00002-g707df13bbbdd #6 [ 13.250561][ T415] Hardware name: Freescale i.MX7 Dual (Device Tree) [ 13.257009][ T415] PC is at 0x0 [ 13.260249][ T415] LR is at rproc_virtio_notify+0x2c/0x54 [ 13.265738][ T415] pc : [<00000000>] lr : [<8050f6b0>] psr: 60010113 [ 13.272702][ T415] sp : b8d47c48 ip : 00000001 fp : bc04de00 [ 13.278625][ T415] r10: bc04c000 r9 : 00000cc0 r8 : b8d46000 [ 13.284548][ T415] r7 : 00000000 r6 : b898f200 r5 : 00000000 r4 : b8a29800 [ 13.291773][ T415] r3 : 00000000 r2 : 990a3ad4 r1 : 00000000 r0 : b8a29800 [ 13.299000][ T415] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 13.306833][ T415] Control: 10c5387d Table: b8b4806a DAC: 00000051 [ 13.313278][ T415] Process unload-load.sh (pid: 415, stack limit = 0x(ptrval)) [ 13.320591][ T415] Stack: (0xb8d47c48 to 0xb8d48000) [ 13.325651][ T415] 7c40: b895b680 00000001 b898f200 803c6430 b895bc80 7f00ae18 [ 13.334531][ T415] 7c60: 00000035 00000000 00000000 b9393200 80b3ed80 00004000 b9393268 bbf5a9a2 [ 13.343410][ T415] 7c80: 00000e00 00000200 00000000 7f00aff0 7f00a014 b895b680 b895b800 990a3ad4 [ 13.352290][ T415] 7ca0: 00000001 b898f210 b898f200 00000000 00000000 7f00e000 00000001 00000000 [ 13.361170][ T415] 7cc0: 00000000 803c62e0 80b2169c 802a0924 b898f210 00000000 00000000 b898f210 [ 13.370049][ T415] 7ce0: 80b9ba44 00000000 80b9ba48 00000000 7f00e000 00000008 80b2169c 80400114 [ 13.378929][ T415] 7d00: 80b2169c 8061fd64 b898f210 7f00e000 80400744 b8d46000 80b21634 80b21634 [ 13.387809][ T415] 7d20: 80b2169c 80400614 80b21634 80400718 7f00e000 00000000 b8d47d7c 80400744 [ 13.396689][ T415] 7d40: b8d46000 80b21634 80b21634 803fe338 b898f254 b80fe76c b8d32e38 990a3ad4 [ 13.405569][ T415] 7d60: fffffff3 b898f210 b8d46000 00000001 b898f254 803ffe7c 80857a90 b898f210 [ 13.414449][ T415] 7d80: 00000001 990a3ad4 b8d46000 b898f210 b898f210 80b17aec b8a29c20 803ff0a4 [ 13.423328][ T415] 7da0: b898f210 00000000 b8d46000 803fb8e0 b898f200 00000000 80b17aec b898f210 [ 13.432209][ T415] 7dc0: b8a29c20 990a3ad4 b895b900 b898f200 8050fb7c 80b17aec b898f210 b8a29c20 [ 13.441088][ T415] 7de0: b8a29800 b895b900 b8a29a04 803c5ec0 b8a29c00 b898f200 b8a29a20 00000007 [ 13.449968][ T415] 7e00: b8a29c20 8050fd78 b8a29800 00000000 b8a29a20 b8a29c04 b8a29820 b8a299d0 [ 13.458848][ T415] 7e20: b895b900 8050e5a4 b8a29800 b8a299d8 b8d46000 b8a299e0 b8a29820 b8a299d0 [ 13.467728][ T415] 7e40: b895b900 8050e008 000041ed 00000000 b8b8c440 b8a299d8 b8a299e0 b8a299d8 [ 13.476608][ T415] 7e60: b8b8c440 990a3ad4 00000000 b8a29820 b8b8c400 00000006 b8a29800 b895b880 [ 13.485487][ T415] 7e80: b8d47f78 00000000 00000000 8050f4b4 00000006 b895b890 b8b8c400 008fbea0 [ 13.494367][ T415] 7ea0: b895b880 8029f530 00000000 00000000 b8d46000 00000006 b8d46000 008fbea0 [ 13.503246][ T415] 7ec0: 8029f434 00000000 b8d46000 00000000 00000000 8021e2e4 0000000a 8061fd0c [ 13.512125][ T415] 7ee0: 0000000a b8af0c00 0000000a b8af0c40 00000001 b8af0c40 00000000 8061f910 [ 13.521005][ T415] 7f00: 0000000a 80240af4 00000002 b8d46000 00000000 8061fd0c 00000002 80232d7c [ 13.529884][ T415] 7f20: 00000000 b8d46000 00000000 990a3ad4 00000000 00000006 b8a62d80 008fbea0 [ 13.538764][ T415] 7f40: b8d47f78 00000000 b8d46000 00000000 00000000 802210c0 b88f2900 00000000 [ 13.547644][ T415] 7f60: b8a62d80 b8a62d80 b8d46000 00000006 008fbea0 80221320 00000000 00000000 [ 13.556524][ T415] 7f80: b8af0c00 990a3ad4 0000006c 008fbea0 76f1cda0 00000004 80101204 00000004 [ 13.565403][ T415] 7fa0: 00000000 80101000 0000006c 008fbea0 00000001 008fbea0 00000006 00000000 [ 13.574283][ T415] 7fc0: 0000006c 008fbea0 76f1cda0 00000004 00000006 00000006 00000000 00000000 [ 13.583162][ T415] 7fe0: 00000004 7ebaf7d0 76eb4c0b 76e3f206 600d0030 00000001 00000000 00000000 [ 13.592056][ T415] [<8050f6b0>] (rproc_virtio_notify) from [<803c6430>] (virtqueue_notify+0x1c/0x34) [ 13.601298][ T415] [<803c6430>] (virtqueue_notify) from [<7f00ae18>] (rpmsg_probe+0x280/0x380 [virtio_rpmsg_bus]) [ 13.611663][ T415] [<7f00ae18>] (rpmsg_probe [virtio_rpmsg_bus]) from [<803c62e0>] (virtio_dev_probe+0x1f8/0x2c4) [ 13.622022][ T415] [<803c62e0>] (virtio_dev_probe) from [<80400114>] (really_probe+0x200/0x450) [ 13.630817][ T415] [<80400114>] (really_probe) from [<80400614>] (driver_probe_device+0x16c/0x1ac) [ 13.639873][ T415] [<80400614>] (driver_probe_device) from [<803fe338>] (bus_for_each_drv+0x84/0xc8) [ 13.649102][ T415] [<803fe338>] (bus_for_each_drv) from [<803ffe7c>] (__device_attach+0xd4/0x164) [ 13.658069][ T415] [<803ffe7c>] (__device_attach) from [<803ff0a4>] (bus_probe_device+0x84/0x8c) [ 13.666950][ T415] [<803ff0a4>] (bus_probe_device) from [<803fb8e0>] (device_add+0x444/0x768) [ 13.675572][ T415] [<803fb8e0>] (device_add) from [<803c5ec0>] (register_virtio_device+0xa4/0xfc) [ 13.684541][ T415] [<803c5ec0>] (register_virtio_device) from [<8050fd78>] (rproc_add_virtio_dev+0xcc/0x1b8) [ 13.694466][ T415] [<8050fd78>] (rproc_add_virtio_dev) from [<8050e5a4>] (rproc_start+0x148/0x200) [ 13.703521][ T415] [<8050e5a4>] (rproc_start) from [<8050e008>] (rproc_boot+0x384/0x5c0) [ 13.711708][ T415] [<8050e008>] (rproc_boot) from [<8050f4b4>] (state_store+0x3c/0xc8) [ 13.719723][ T415] [<8050f4b4>] (state_store) from [<8029f530>] (kernfs_fop_write+0xfc/0x214) [ 13.728348][ T415] [<8029f530>] (kernfs_fop_write) from [<8021e2e4>] (__vfs_write+0x30/0x1cc) [ 13.736971][ T415] [<8021e2e4>] (__vfs_write) from [<802210c0>] (vfs_write+0xac/0x17c) [ 13.744985][ T415] [<802210c0>] (vfs_write) from [<80221320>] (ksys_write+0x64/0xe4) [ 13.752825][ T415] [<80221320>] (ksys_write) from [<80101000>] (ret_fast_syscall+0x0/0x54) [ 13.761178][ T415] Exception stack(0xb8d47fa8 to 0xb8d47ff0) [ 13.766932][ T415] 7fa0: 0000006c 008fbea0 00000001 008fbea0 00000006 00000000 [ 13.775811][ T415] 7fc0: 0000006c 008fbea0 76f1cda0 00000004 00000006 00000006 00000000 00000000 [ 13.784687][ T415] 7fe0: 00000004 7ebaf7d0 76eb4c0b 76e3f206 [ 13.790442][ T415] Code: bad PC value [ 13.839214][ T415] ---[ end trace 1fe21ecfc9f28852 ]--- Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Nikita Shubin <NShubin@topcon.com> Fixes: 7a186941626d ("remoteproc: remove the single rpmsg vdev limitation") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200306072452.24743-1-NShubin@topcon.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: return error for bad "recovery" debugfs inputAlex Elder
If the value written to the "recovery" debugfs file is not one of the recognized commands return an error to indicate it's invalid. Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20200228183359.16229-5-elder@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: remoteproc debugfs file fixesAlex Elder
Don't bother checking the remoteproc state before calling rproc_trigger_recovery() because that function will verify the state, and the state can only be safely checked while holding the mutex anyway. Make the mode for "recovery" be writable. Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20200228183359.16229-3-elder@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: re-check state in rproc_trigger_recovery()Alex Elder
Two places call rproc_trigger_recovery(): - rproc_crash_handler_work() sets rproc->state to CRASHED under protection of the mutex, then calls it if recovery is not disabled. This function is called in workqueue context when scheduled in rproc_report_crash(). - rproc_recovery_write() calls it in two spots, both of which the only call it if the rproc->state is CRASHED. The mutex is taken right away in rproc_trigger_recovery(). However, by the time the mutex is acquired, something else might have changed rproc->state to something other than CRASHED. The work that follows that is only appropriate for a remoteproc in CRASHED state. So check the state after acquiring the mutex, and only proceed with the recovery work if the remoteproc is still in CRASHED state. Delay reporting that recovering has begun until after we hold the mutex and we know the remote processor is in CRASHED state. Signed-off-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20200228183359.16229-2-elder@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: stm32: demote warning about optional property absenceAhmad Fatoum
The mainline device trees lack the "st,syscfg-pdds", so probing the driver always throws the warning. As the property is optional per binding and the driver can deal with its absence, demote the warning to info log level. Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.kernel.org/r/20200224172519.15315-1-a.fatoum@pengutronix.de Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc/mediatek: Use size_t type for len in scp_da_to_vaNathan Chancellor
Clang errors: drivers/remoteproc/mtk_scp.c:364:14: error: incompatible function pointer types initializing 'void *(*)(struct rproc *, u64, size_t)' (aka 'void *(*)(struct rproc *, unsigned long long, unsigned int)') with an expression of type 'void *(struct rproc *, u64, int)' (aka 'void *(struct rproc *, unsigned long long, int)') [-Werror,-Wincompatible-function-pointer-types] .da_to_va = scp_da_to_va, ^~~~~~~~~~~~ 1 error generated. Make the same change as commit 0fcbb369f052 ("remoteproc: Use size_t type for len in da_to_va"), which was not updated for the acceptance of commit 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183"). Fixes: 0fcbb369f052 ("remoteproc: Use size_t type for len in da_to_va") Link: https://github.com/ClangBuiltLinux/linux/issues/927 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Link: https://lore.kernel.org/r/20200310211514.32288-1-natechancellor@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Adapt coredump to generate correct elf typeClement Leger
Now that remoteproc can load an elf64, coredump elf class should be the same as the loaded elf class. In order to do that, add a elf_class field to rproc with default values. If an elf is loaded successfully, this field will be updated with the loaded elf class. Then, the coredump core code has been modified to use the generic elf macro in order to create an elf file with correct class. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-9-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Allow overriding only sanity_checkClement Leger
Now that rproc_elf_sanity_check can be used by external drivers, allow to only overwrite the sanity_check member of rproc_ops. This will allow drivers to handle elf32 and elf64 by overwriting sanity_check with rproc_elf_sanity_check function. Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-8-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Add elf64 support in elf loaderClement Leger
In order to support elf64, use macros from remoteproc_elf_helpers.h to access elf headers depending on elf class. To allow new drivers to support elf64, add rproc_elf_sanity_check function which make more sense than adding a elf64 named one since it will support both elf versions. Driver which need to support both elf32/elf64 should use this new function for elf sanity check instead of the elf32 one. Signed-off-by: Clement Leger <cleger@kalray.eu> Tested-by: Arnaud POULIQUEN <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200302093902.27849-7-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Rename rproc_elf_sanity_check for elf32Clement Leger
Since this function will be modified to support both elf32 and elf64, rename the existing one to elf32 (which is the only supported format at the moment). This will allow not to introduce possible side effect when adding elf64 support (ie: all backends will still support only elf32 if not requested explicitely using rproc_elf_sanity_check). Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-6-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Add elf helpers to access elf64 and elf32 fieldsClement Leger
elf32 and elf64 mainly differ by their types. In order to avoid copy/pasting the whole loader code, generate static inline functions which will access values according to the elf class. It allows to keep a common loader basis. In order to accommodate both elf types sizes, the maximum size for a elf header member is chosen using the maximum value of the field for both elf class. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-5-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Use u64 type for boot_addrClement Leger
elf64 entry is defined as a u64. Since boot_addr is used to store the elf entry point, change boot_addr type to u64 to support both elf32 and elf64. In the same time, fix users that were using this variable. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-4-cleger@kalray.eu [bjorn: Fixes up return type of rproc_get_boot_addr()] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Use size_t instead of int for rproc_mem_entry lenClement Leger
Now that rproc_da_to_va uses a size_t for length, use a size_t for len field of rproc_mem_entry. Function used to create such structures now takes a size_t instead of int to allow full size range to be handled. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-3-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: Use size_t type for len in da_to_vaClement Leger
With upcoming changes in elf loader for elf64 support, section size will be a u64. When used with da_to_va, this will potentially lead to overflow if using the current "int" type for len argument. Change da_to_va prototype to use a size_t for len and fix all users of this function. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Clement Leger <cleger@kalray.eu> Link: https://lore.kernel.org/r/20200302093902.27849-2-cleger@kalray.eu Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: fix kernel-doc warningsArnaud Pouliquen
Fix the following warnings when documentation is built: drivers/remoteproc/remoteproc_virtio.c:330: warning: Function parameter or member 'id' not described in 'rproc_add_virtio_dev' drivers/remoteproc/remoteproc_core.c:243: warning: Function parameter or member 'name' not described in 'rproc_find_carveout_by_name' drivers/remoteproc/remoteproc_core.c:473: warning: Function parameter or member 'offset' not described in 'rproc_handle_vdev' drivers/remoteproc/remoteproc_core.c:604: warning: Function parameter or member 'offset' not described in 'rproc_handle_trace' drivers/remoteproc/remoteproc_core.c:678: warning: Function parameter or member 'offset' not described in 'rproc_handle_devmem' drivers/remoteproc/remoteproc_core.c:873: warning: Function parameter or member 'offset' not described in 'rproc_handle_carveout' drivers/remoteproc/remoteproc_core.c:1029: warning: cannot understand function prototype: 'rproc_handle_resource_t rproc_loading_handlers[RSC_LAST] = ' drivers/remoteproc/remoteproc_core.c:1693: warning: Function parameter or member 'work' not described in 'rproc_crash_handler_work' Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com> Link: https://lore.kernel.org/r/20200212161956.10358-1-arnaud.pouliquen@st.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: qcom_q6v5_mss: Reload the mba region on coredumpSibi Sankar
On secure devices after a wdog/fatal interrupt, the mba region has to be refreshed in order to prevent the following errors during mba load. Err Logs: remoteproc remoteproc2: stopped remote processor 4080000.remoteproc qcom-q6v5-mss 4080000.remoteproc: PBL returned unexpected status -284031232 qcom-q6v5-mss 4080000.remoteproc: PBL returned unexpected status -284031232 .... qcom-q6v5-mss 4080000.remoteproc: PBL returned unexpected status -284031232 qcom-q6v5-mss 4080000.remoteproc: MBA booted, loading mpss Fixes: 7dd8ade24dc2a ("remoteproc: qcom: q6v5-mss: Add custom dump function for modem") Cc: stable@vger.kernel.org Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200304194729.27979-4-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: qcom_q6v5_mss: Validate each segment during loadingBjorn Andersson
The code used to sync with the MBA after each segment loaded and this is still what's done downstream. So reduce the delta towards downstream by switching to a model where the content is iteratively validated. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200304194729.27979-3-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25remoteproc: qcom_q6v5_mss: Don't reassign mpss region on shutdownBjorn Andersson
Trying to reclaim mpss memory while the mba is not running causes the system to crash on devices with security fuses blown, so leave it assigned to the remote on shutdown and recover it on a subsequent boot. Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem ownership switch") Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200304194729.27979-2-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-25Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller
Overlapping header include additions in macsec.c A bug fix in 'net' overlapping with the removal of 'version' string in ena_netdev.c Overlapping test additions in selftests Makefile Overlapping PCI ID table adjustments in iwlwifi driver. Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-25clk: imx: Align imx sc clock parent msg structs to 4Leonard Crestez
The imx SC api strongly assumes that messages are composed out of 4-bytes words but some of our message structs have odd sizeofs. This produces many oopses with CONFIG_KASAN=y. Fix by marking with __aligned(4). Fixes: 666aed2d13ee ("clk: imx: scu: add set parent support") Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Link: https://lkml.kernel.org/r/aad021e432b3062c142973d09b766656eec18fde.1582216144.git.leonard.crestez@nxp.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-25clk: imx: Align imx sc clock msg structs to 4Leonard Crestez
The imx SC api strongly assumes that messages are composed out of 4-bytes words but some of our message structs have odd sizeofs. This produces many oopses with CONFIG_KASAN=y. Fix by marking with __aligned(4). Fixes: fe37b4820417 ("clk: imx: add scu clock common part") Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Link: https://lkml.kernel.org/r/10e97a04980d933b2cfecb6b124bf9046b6e4f16.1582216144.git.leonard.crestez@nxp.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2020-03-25ACPI: NFIT: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200319195046.GA452@embeddedor.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2020-03-26pinctrl: freescale: drop the dependency on ARM64 for i.MX8MPeng Fan
Moving to support aarch32 mode on aarch64 hardware, need to drop the dependency on ARM64 to make the driver could be selected for ARM32. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1584070036-26447-2-git-send-email-peng.fan@nxp.com Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-26Revert "pinctrl: mvebu: armada-37xx: use use platform api"Linus Walleij
This reverts commit 06e26b75f5e613b400116fdb7ff6206a681ab271. According to discussions, it causes a regression. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-26gpio: brcmstb: support gpio-line-names propertyDoug Berger
The default handling of the gpio-line-names property by the gpiolib-of implementation does not work with the multiple gpiochip banks per device structure used by the gpio-brcmstb driver. This commit adds driver level support for the device tree property so that GPIO lines can be assigned friendly names. Signed-off-by: Doug Berger <opendmb@gmail.com> Link: https://lore.kernel.org/r/1583780521-45702-1-git-send-email-opendmb@gmail.com Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-25Merge branch 'nvme-5.7-rc1' of git://git.infradead.org/nvme into for-5.7/driversJens Axboe
Pull 5.7 NVMe updates from Keith. * 'nvme-5.7-rc1' of git://git.infradead.org/nvme: (42 commits) nvme: cleanup namespace identifier reporting in nvme_init_ns_head nvme: rename __nvme_find_ns_head to nvme_find_ns_head nvme: refactor nvme_identify_ns_descs error handling nvme-tcp: Add warning on state change failure at nvme_tcp_setup_ctrl nvme-rdma: Add warning on state change failure at nvme_rdma_setup_ctrl nvme: Fix controller creation races with teardown flow nvme: Make nvme_uninit_ctrl symmetric to nvme_init_ctrl nvme: Fix ctrl use-after-free during sysfs deletion nvme-pci: Re-order nvme_pci_free_ctrl nvme: Remove unused return code from nvme_delete_ctrl_sync nvme: Use nvme_state_terminal helper nvme: release ida resources nvme: Add compat_ioctl handler for NVME_IOCTL_SUBMIT_IO nvmet-tcp: optimize tcp stack TX when data digest is used nvme-fabrics: Use scnprintf() for avoiding potential buffer overflow nvme-multipath: do not reset on unknown status nvmet-rdma: allocate RW ctxs according to mdts nvmet-rdma: Implement get_mdts controller op nvmet: Add get_mdts op for controllers nvme-pci: properly print controller address ...
2020-03-25Merge tag 'imx-dt64-5.7' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/dt i.MX arm64 DTS update for 5.7: - New support for Kontron LS1028A based boards and NXP i.MX8MP EVK. - Add Ethernet PHY reset GPIO for imx8mm-evk and imx8mq-evk board. - Add gpio-fan, thermal and Ethernet support for imx8mq-phanbell board. - Add SNVS clock description to pwrkey device for i.MX8 SoCs. - A number of updates on librem5-devkit board to add audio, proximity sensor, lsm9ds1 mount matrix support, and improve WoWWAN, DVFS, SD devices as well. - A series of patches from Anson Huang to update i.MX8 EVK boards for support of I2C PCA6416, thermal, GPIO LED, OPP table etc. - Add PCIe device nodes for LX2160A and LS1028A SoC. - Add FSPI deivce support for LX2160A evaluation boards. - Add EEPROM and LTC3882 regulator support for lx2160a-cex7 board. - Other small and random updates on LS1028A and i.MX8 support. * tag 'imx-dt64-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: (63 commits) arm64: dts: ls1028a: disable the felix switch by default arm64: dts: imx8mp: Add snvs clock to powerkey arm64: dts: imx8mn: Add snvs clock to powerkey arm64: dts: ls1028a: Add PCIe controller DT nodes arm64: dts: ls1028a: sl28: add support for variant 2 arm64: dts: ls1028a: sl28: expose switch ports in KBox A-230-LS arm64: dts: ls1028a: sl28: fix on-board EEPROMS arm64: dts: freescale: sl28: add SPI flash arm64: dts: imx8m: fix aips dts node arm64: dts: imx8mn: Add CPU thermal zone support arm64: dts: imx8mm: Add thermal zone support arm64: dts: imx8mq-phanbell: Fix Ethernet PHY post-reset duration arm64: dts: enable fspi in imx8mm dts arm64: dts: imx8mn: align name for crypto child nodes arm64: dts: lx2160aqds: Add FSPI node properties arm64: dts: lx2160ardb: Update FSPI node properties arm64: dts: imx8mq-phanbell: Add gpio-fan/thermal support arm64: dts: layerscape: add iommu-map property to pci nodes arm64: dts: imx8mp-evk: Enable pca6416 on i2c3 bus arm64: dts: imx8mp-evk: Add i2c3 support ... Link: https://lore.kernel.org/r/20200318051918.32579-5-shawnguo@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-03-25mtd: rawnand: toshiba: Support reading the number of bitflips for BENAND ↵Yoshio Furuyama
(Built-in ECC NAND) Add support vendor specific commands for KIOXIA CORPORATION BENAND. The actual bitflips number can be retrieved by this command. Signed-off-by: Yoshio Furuyama <ytc-mb-yfuruyama7@kioxia.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1585124572-4693-1-git-send-email-ytc-mb-yfuruyama7@kioxia.com
2020-03-25Merge tag 'spi-nor/for-5.7' into mtd/nextMiquel Raynal
SPI NOR core changes: - move all the manufacturer specific quirks/code out of the core, to make the core logic more readable and thus ease maintenance. - move the SFDP logic out of the core, it provides a better separation between the SFDP parsing and core logic. - trim what is exposed in spi-nor.h. The SPI NOR controllers drivers must not be able to use structures that are meant just for the SPI NOR core. - use the spi-mem direct mapping API to let advanced controllers optimize the read/write operations when they support direct mapping. - add generic formula for the Status Register block protection handling. It fixes some long standing locking limitations and eases the addition of the 4bit block protection support. - add block protection support for flashes with 4 block protection bits in the Status Register. SPI NOR controller drivers changes: - the mtk-quadspi driver is replaced by the new spi-mem spi-mtk-nor driver. Merge tag 'mtk-mtd-spi-move' into spi-nor/next to avoid conflicts.
2020-03-25Merge tag 'cfi/for-5.7' into mtd/nextMiquel Raynal
HyperBus changes * Print err msg when compatible is wrong or missing * Move mapping of direct access window from core to individual drivers
2020-03-25drm/amdgpu: don't try to reserve training bo for sriov (v2)Monk Liu
1) SRIOV guest KMD doesn't care training buffer 2) if we resered training buffer that will overlap with IP discovery reservation because training buffer is at vram_size - 0x8000 and IP discovery is at ()vram_size - 0x10000 => vram_size -1) v2: squash in warning fix from Nirmoy Signed-off-by: Monk Liu <Monk.Liu@amd.com> Reviewed-by: Emily Deng <Emily.Deng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amdgpu/smu11: add support for SMU AC/DC interruptsAlex Deucher
Driver needs to send the ack message when it receives the AC/DC interrupt from the SMU. TODO: verify the client and src ids. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amdgpu/swSMU: handle manual AC/DC notificationsAlex Deucher
For boards that do not support automatic AC/DC transitions in firmware, manually tell the firmware when the status changes. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amdgpu/swSMU: handle DC controlled by GPIO for navi1xAlex Deucher
Check the platform caps in the vbios pptable to decide whether to enable automatic AC/DC transitions. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amdgpu/swSMU: set AC/DC mode based on the current system state (v2)Alex Deucher
Check of the pointer exists and we are actually on AC power. v2: fix error message to reflect AC/DC mode. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amdgpu/swSMU: correct the bootup power source for Navi1X (v2)Evan Quan
PMFW may boots those ASICs with DC mode. Need to set it back to AC mode. v2: split from Evan's original patch (Alex) Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amdgpu/swSMU: use the smu11 power source helper for navi1xAlex Deucher
The smu_v11_0 version works for navi1x. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amdgpu/smu11: add a helper to set the power sourceAlex Deucher
Add a common smu11 helper to set the AC/DC power source. Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amd/swSMU: add callback to set AC/DC power source (v2)Evan Quan
This is needed to tell the SMU firmware what state is in in certain cases. DC mode does not allow overclocking for example. v2: split Evan's original patch (Alex) Bug: https://gitlab.freedesktop.org/drm/amd/issues/1043 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/scheduler: fix rare NULL ptr raceYintian Tao
There is one one corner case at dma_fence_signal_locked which will raise the NULL pointer problem just like below. ->dma_fence_signal ->dma_fence_signal_locked ->test_and_set_bit here trigger dma_fence_release happen due to the zero of fence refcount. ->dma_fence_put ->dma_fence_release ->drm_sched_fence_release_scheduled ->call_rcu here make the union fled “cb_list” at finished fence to NULL because struct rcu_head contains two pointer which is same as struct list_head cb_list Therefore, to hold the reference of finished fence at drm_sched_process_job to prevent the null pointer during finished fence dma_fence_signal [ 732.912867] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 732.914815] #PF: supervisor write access in kernel mode [ 732.915731] #PF: error_code(0x0002) - not-present page [ 732.916621] PGD 0 P4D 0 [ 732.917072] Oops: 0002 [#1] SMP PTI [ 732.917682] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G OE 5.4.0-rc7 #1 [ 732.918980] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 [ 732.920906] RIP: 0010:dma_fence_signal_locked+0x3e/0x100 [ 732.938569] Call Trace: [ 732.939003] <IRQ> [ 732.939364] dma_fence_signal+0x29/0x50 [ 732.940036] drm_sched_fence_finished+0x12/0x20 [gpu_sched] [ 732.940996] drm_sched_process_job+0x34/0xa0 [gpu_sched] [ 732.941910] dma_fence_signal_locked+0x85/0x100 [ 732.942692] dma_fence_signal+0x29/0x50 [ 732.943457] amdgpu_fence_process+0x99/0x120 [amdgpu] [ 732.944393] sdma_v4_0_process_trap_irq+0x81/0xa0 [amdgpu] v2: hold the finished fence at drm_sched_process_job instead of amdgpu_fence_process v3: resume the blank line Signed-off-by: Yintian Tao <yttao@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amdgpu: fix the coverage issue to clear ArcVPGRsDennis Li
Set ComputePGMRSRC1.VGPRS as 0x3f to clear all ArcVGPRs. Signed-off-by: Dennis Li <Dennis.Li@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/amd/display: Fix pageflip event race condition for DCN.Mario Kleiner
Commit '16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup for DCN")' introduces a new way of pageflip completion handling for DCN, and some trouble. The current implementation introduces a race condition, which can cause pageflip completion events to be sent out one vblank too early, thereby confusing userspace and causing flicker: prepare_flip_isr(): 1. Pageflip programming takes the ddev->event_lock. 2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED 3. Releases ddev->event_lock. --> Deadline for surface address regs double-buffering passes on target pipe. 4. dc_commit_updates_for_stream() MMIO programs the new pageflip into hw, but too late for current vblank. => pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete in current vblank due to missing the double-buffering deadline by a tiny bit. 5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires, dm_dcn_crtc_high_irq() gets called. 6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the pageflip has been completed/will complete in this vblank and sends out pageflip completion event to userspace and resets pflip_status = AMDGPU_FLIP_NONE. => Flip completion event sent out one vblank too early. This behaviour has been observed during my testing with measurement hardware a couple of time. The commit message says that the extra flip event code was added to dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events in case the pflip irq doesn't fire, because the "DCH HUBP" component is clock gated and doesn't fire pflip irqs in that state. Also that this clock gating may happen if no planes are active. This suggests that the problem addressed by that commit can't happen if planes are active. The proposed solution is therefore to only execute the extra pflip completion code iff the count of active planes is zero and otherwise leave pflip completion handling to the pflip irq handler, for a more race-free experience. Note that i don't know if this fixes the problem the original commit tried to address, as i don't know what the test scenario was. It does fix the observed too early pageflip events though and points out the problem introduced. Fixes: 16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup for DCN") Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-25drm/panel-simple: drop use of data-mapping propertySam Ravnborg
The "data-mapping" property may not be the best way to describe the interface between panels and display interfaces. Drop use of in the panel-simple driver, so we have time to find the right way to describe this interface. Fixes: 4a1d0dbc8332 ("drm/panel: simple: add panel-dpi support") Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Oleksandr Suvorov <oleksandr.suvorov@toradex.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Cc: Rob Herring <robh@kernel.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200314153047.2486-3-sam@ravnborg.org
2020-03-25drm/[radeon|amdgpu]: Remove HAINAN board from max_sclk override checkYassine Oudjana
Works stable without the overrides. Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-18 00:32:55 +0000