- 02 Oct, 2023 7 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> # qcom Link: https://lore.kernel.org/r/20230925095532.1984344-25-u.kleine-koenig@pengutronix.deSigned-off-by:
Bjorn Andersson <andersson@kernel.org>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230925095532.1984344-21-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
-
- 27 Sep, 2023 6 commits
-
-
Kathiravan Thirumoorthy authored
Per the "SMC calling convention specification", the 64-bit calling convention can only be used when the client is 64-bit. Whereas the 32-bit calling convention can be used by either a 32-bit or a 64-bit client. Currently during SCM probe, irrespective of the client, 64-bit calling convention is made, which is incorrect and may lead to the undefined behaviour when the client is 32-bit. Let's fix it. Cc: stable@vger.kernel.org Fixes: 9a434cee ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Reviewed-By:
Elliot Berman <quic_eberman@quicinc.com> Signed-off-by:
Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> Link: https://lore.kernel.org/r/20230925-scm-v3-1-8790dff6a749@quicinc.comSigned-off-by:
-
Uwe Kleine-König authored
Usually there is only one llcc device. But if there were a second, even a failed probe call would modify the global drv_data pointer. So check if drv_data is valid before overwriting it. Signed-off-by:
-
Unnathi Chalicheemala authored
Switch to GPL version of EXPORT_SYMBOL for Qualcomm SoC drivers. Signed-off-by:
Unnathi Chalicheemala <quic_uchalich@quicinc.com> Reviewed-by:
Trilok Soni <quic_tsoni@quicinc.com> Link: https://lore.kernel.org/r/20230922184817.5183-1-quic_uchalich@quicinc.comSigned-off-by:
-
Kees Cook authored
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct qcom_smem. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Andy Gross <agross@kernel.org> Cc: Bjorn Andersson <andersson@kernel.org> Cc: Konrad Dybcio <konrad.dybcio@linaro.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Tom Rix <trix@redhat.com> Cc: linux-arm-msm@vger.kernel.org Cc: llvm@lists.linux.dev Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
"Gustavo A. R. Silva" <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230922175413.work.929-kees@kernel.orgSigned-off-by:
-
Bjorn Andersson authored
In some configurations, the exact placement of the rmtfs shared memory region isn't so strict. The DeviceTree author can then choose to use the "size" property and rely on the OS for placement (in combination with "alloc-ranges", if desired). But on some platforms the rmtfs memory region may not be allocated adjacent to regions allocated by other clients. Add support for discarding the first and last 4k block in the region, if qcom,use-guard-pages is specified in DeviceTree. Signed-off-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by:
Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20230920-rmtfs-mem-guard-pages-v3-2-305b37219b78@quicinc.comSigned-off-by:
-
Bjorn Andersson authored
On some Qualcomm platforms the firwmare, or hardware, does not gracefully handle memory protection of the rmtfs memory region when placed adjacent to other protected region. Some DeviceTree authors have worked around this issue by explicitly reserving the space around the region, but this prevents such author to use rely on the OS to place the region, through the use of "size" (instead of a fixed location). Introduce a flag to indicate that guard pages need be carved at the beginning and end of the memory region. The user shall account for the two pages in the defined size. Signed-off-by:
-
- 20 Sep, 2023 10 commits
-
-
Robert Marko authored
It seems that IPQ5018 compatible was never documented in the bindings. Signed-off-by:
Robert Marko <robimarko@gmail.com> Reviewed-by:
-
Robert Marko authored
IPQ5018 has SDI (Secure Debug Image) enabled by TZ by default, and that means that WDT being asserted or just trying to reboot will hang the board in the debug mode and only pulling the power and repowering will help. Some IPQ4019 boards like Google WiFI have it enabled as well. Luckily, SDI can be disabled via an SCM call. So, lets use the boolean DT property to identify boards that have SDI enabled by default and use the SCM call to disable SDI during SCM probe. It is important to disable it as soon as possible as we might have a WDT assertion at any time which would then leave the board in debug mode, thus disabling it during SCM removal is not enough. Signed-off-by:
Guru Das Srinagesh <quic_gurus@quicinc.com> Link: https://lore.kernel.org/r/20230816164641.3371878-2-robimarko@gmail.comSigned-off-by:
-
Robert Marko authored
IPQ5018 has SDI (Secure Debug Image) enabled by TZ by default, and that means that WDT being asserted or just trying to reboot will hang the board in the debug mode and only pulling the power and repowering will help. Some IPQ4019 boards like Google WiFI have it enabled as well. So, lets add a boolean property to indicate that SDI is enabled by default and thus needs to be disabled by the kernel. Signed-off-by:
Mukesh Ojha <quic_mojha@quicinc.com> Reviewed-by:
Brian Norris <computersforpeace@gmail.com> Link: https://lore.kernel.org/r/20230816164641.3371878-1-robimarko@gmail.comSigned-off-by:
-
Danila Tikhonov authored
Document the compatible for Qualcomm SM7150 SCM. Signed-off-by:
Danila Tikhonov <danila@jiaxyga.com> Acked-by:
-
Komal Bajaj authored
Add LLCC configuration data for QDU1000 and QRU1000 SoCs. Signed-off-by:
Komal Bajaj <quic_kbajaj@quicinc.com> Reviewed-by:
-
Komal Bajaj authored
Update macro name for LLCC_DRE to LLCC_ECC as per the latest specification. Signed-off-by:
-
Komal Bajaj authored
Add LLCC support for multi channel DDR configuration based on a feature register. Signed-off-by:
-
Komal Bajaj authored
Add the stub nvmem_cell_read_u8() function for drivers running with CONFIG_NVMEM disabled. Signed-off-by:
-
Komal Bajaj authored
Refactor driver to support multiple configuration for llcc on a target. Signed-off-by:
-
Komal Bajaj authored
Add LLCC compatible for QDU1000/QRU1000 SoCs and add optional nvmem-cells and nvmem-cell-names properties to support multiple configurations for multi channel DDR. Signed-off-by:
-
- 19 Sep, 2023 1 commit
-
-
Lu Hongfei authored
The device_for_each_child_node loop should call fwnode_handle_put() before return in the error cases, to avoid resource leaks. Let's fix this bug in pmic_glink_altmode_probe(). Signed-off-by:
Lu Hongfei <luhongfei@vivo.com> Link: https://lore.kernel.org/r/20230612133452.47315-1-luhongfei@vivo.com [bjorn: Rebased patch, moved fw_handle_put() from jump target into the loop] Signed-off-by:
-
- 16 Sep, 2023 1 commit
-
-
Bjorn Andersson authored
The newly introduced QSEECOM driver fail to link if the system is built without CONFIG_AUXILIARY_BUS, make sure it is selected. Fixes: 00b12486 ("firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface") Reported-by:
Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/r/9f156fa6-e5aa-4cb2-ab2b-b67fd8fc4840%40infradead.orgSigned-off-by:
-
- 14 Sep, 2023 2 commits
-
-
Bartosz Golaszewski authored
For easier maintenance order the included headers in qcom_scm.c alphabetically. Signed-off-by:
Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by:
-
Bartosz Golaszewski authored
The 'extern' specifier in front of a function declaration has no effect. Remove all of them from the qcom-scm header. Signed-off-by:
-
- 13 Sep, 2023 12 commits
-
-
Robert Marko authored
IPQ8174 (Oak) family is part of the IPQ8074 family, but the ID-s for it are missing so lets add them. Signed-off-by:
-
Robert Marko authored
IPQ8174 (Oak) family is part of the IPQ8074 family, but the ID-s for it are missing so lets add them. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230901181041.1538999-1-robimarko@gmail.comSigned-off-by:
-
Konrad Dybcio authored
On SM8550, the QUP controller is coherent with the CPU. Allow specifying that. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230830-topic-8550_dmac2-v1-2-49bb25239fb1@linaro.orgSigned-off-by:
-
Luca Weiss authored
Add SoC ID table entries for Qualcomm QCM6490. Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Reviewed-by:
-
Luca Weiss authored
Add the ID for the Qualcomm QCM6490 SoC. Signed-off-by:
-
Konrad Dybcio authored
Many of the PMICs were missing, add some of them often coupled with SM8550. Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20230830-topic-pm8550abcxyz-v1-1-3c3ef3d92d51@linaro.orgSigned-off-by:
-
Li Zetao authored
The module_rpmsg_driver() will set "THIS_MODULE" to driver.owner when register a rpmsg_driver driver, so it is redundant initialization to set driver.owner in the statement. Remove it for clean code. Signed-off-by:
Li Zetao <lizetao1@huawei.com> Link: https://lore.kernel.org/r/20230808021446.2975843-1-lizetao1@huawei.comSigned-off-by:
-
Danila Tikhonov authored
Add Soc ID table entries for Qualcomm SM7150P. Signed-off-by:
-
Danila Tikhonov authored
Add the ID for the Qualcomm SM7150P SoC. Signed-off-by:
-
Maximilian Luz authored
On platforms using the Qualcomm UEFI Secure Application (uefisecapp), EFI variables cannot be accessed via the standard interface in EFI runtime mode. The respective functions return EFI_UNSUPPORTED. On these platforms, we instead need to talk to uefisecapp. This commit provides support for this and registers the respective efivars operations to access EFI variables from the kernel. Communication with uefisecapp follows the Qualcomm QSEECOM / Secure OS conventions via the respective SCM call interface. This is also the reason why variable access works normally while boot services are active. During this time, said SCM interface is managed by the boot services. When calling ExitBootServices(), the ownership is transferred to the kernel. Therefore, UEFI must not use that interface itself (as multiple parties accessing this interface at the same time may lead to complications) and cannot access variables for us. Signed-off-by:
Maximilian Luz <luzmaximilian@gmail.com> Acked-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-4-luzmaximilian@gmail.comSigned-off-by:
-
Maximilian Luz authored
Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by:
-
Maximilian Luz authored
Add a ucs2_strscpy() function for UCS-2 strings. The behavior is equivalent to the standard strscpy() function, just for 16-bit character UCS-2 strings. Signed-off-by:
-
- 10 Sep, 2023 1 commit
-
-
Linus Torvalds authored
-
