- 17 Dec, 2023 1 commit
-
-
Ayush Singh authored
Make gb-beagleplay greybus spec compliant by moving cport information to transport layer instead of using `header->pad` bytes. Greybus HDLC frame now has the following payload: 1. le16 cport 2. gb_operation_msg_hdr msg_header 3. u8 *msg_payload Fixes: ec558bbf ("greybus: Add BeaglePlay Linux Driver") Signed-off-by:
Ayush Singh <ayushdevel1325@gmail.com> Link: https://lore.kernel.org/r/20231217121133.74703-2-ayushdevel1325@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 Dec, 2023 39 commits
-
-
Cameron Williams authored
Add device IDs for the Brainboxes UC-203, UC-257, UC-414, UC-475, IS-300/IS-500 and PX-263/PX-295 and define the relevant "geometry" for the cards. This patch requires part 1 of this series. Cc: <stable@vger.kernel.org> Signed-off-by:
Cameron Williams <cang1@live.co.uk> Acked-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Link: https://lore.kernel.org/r/AS4PR02MB7903A4094564BE28F1F926A6C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.comSigned-off-by:
-
Cameron Williams authored
Add BAR/enum entries for Brainboxes serial/parallel cards. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Michal Simek authored
There is no user for this interface that's why remove it. Signed-off-by:
Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/e52a415a004e28a43e6d08e9e22d9e8fef3737df.1702565618.git.michal.simek@amd.comSigned-off-by:
-
Michal Simek authored
As per the current code base, PM_CLOCK_SETRATE and PM_CLOCK_GETRATE APIs are not supported for the runtime operations. In the case of ZynqMP returning an error from TF-A when there is any request to access these APIs and for Versal also it is returning an error like NO_ACCESS from the firmware. So, just removing the unused code to avoid the confusion around these APIs. Also, there is no issue with the backward compatibility as these APIs were never used since implemented. Hence no need to bump up the version of the feature check API as well. Signed-off-by:
Ronak Jain <ronak.jain@amd.com> Signed-off-by:
-
Christophe JAILLET authored
Remove VMCI_HANDLE_ARRAY_HEADER_SIZE and VMCI_HANDLE_ARRAY_MAX_CAPACITY that are unused. Suggested-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
Christophe JAILLET authored
Use struct_size() instead of handle_arr_calc_size(). This is much more conventional. While at it, use size_add() when computing the needed size in vmci_handle_arr_append_entry(). This prevents from (unlikely) overflow when computing the new size to reallocate. Suggested-by:
-
Sen Chu authored
Add device id check for spmi write API. Signed-off-by:
Sen Chu <sen.chu@mediatek.com> Link: https://lore.kernel.org/r/20230518040729.8789-1-sen.chu@mediatek.comReviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20231206231733.4031901-9-sboyd@kernel.orgSigned-off-by:
-
Fei Shao authored
spmi_controller_alloc() currently returns NULL to all types of errors, which can be improved. Use appropriate error code in returns and pass the errors from used functions where possible. Signed-off-by:
Fei Shao <fshao@chromium.org> Link: https://lore.kernel.org/r/20230824104101.4083400-6-fshao@chromium.orgSigned-off-by:
-
Fei Shao authored
Convert to the device-managed version of spmi_controller_add() and delete the unnecessary driver remove callback. Signed-off-by:
-
Fei Shao authored
This driver enables clocks and then adds SPMI controller in probing, so we expect the reversed sequence in removal. Fix the order in the remove callback. Signed-off-by:
-
Fei Shao authored
Convert to the device-managed version of spmi_controller_alloc() and simplify the excess error handling code. Signed-off-by:
-
Fei Shao authored
Utilize the managed resource (devres) framework and add the following devm_* helpers for the SPMI driver: - devm_spmi_controller_alloc() - devm_spmi_controller_add() [sboyd@kernel.org: Rename to spmi-devres for module niceness, slap on GPL module license] Signed-off-by:
-
Yu-Che Cheng authored
The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller. Reported-by:
Yu-Che Cheng <giver@chromium.org> Link: https://lore.kernel.org/r/20230717173934.1.If004a6e055a189c7f2d0724fa814422c26789839@changeidTested-by:
Chen-Yu Tsai <wenst@chromium.org> Signed-off-by:
-
Nícolas F. R. A. Prado authored
Before writing the read or write command to the SPMI arbiter through the PMIF interface, the current status of the channel is checked to ensure it is idle. However, since the status only changes from idle when the command is written, it is possible for two concurrent calls to determine that the channel is idle and simultaneously send their commands. At this point the PMIF interface hangs, with the status register no longer being updated, and thus causing all subsequent operations to time out. This was observed on the mt8195-cherry-tomato-r2 machine, particularly after commit 46600ab1 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers between 5.10 and 5.15") was applied, since then the two MT6315 devices present on the SPMI bus would probe assynchronously and sometimes (during probe or at a later point) read the bus simultaneously, breaking the PMIF interface and consequently slowing down the whole system. To fix the issue at its root cause, introduce locking around the channel status check and the command write, so that both become an atomic operation, preventing race conditions between two (or more) SPMI bus read/write operations. A spinlock is used since this is a fast bus, as indicated by the usage of the atomic variant of readl_poll, and '.fast_io = true' being used in the mt6315 driver, so spinlocks are already used for the regmap access. Fixes: b45b3cce ("spmi: mediatek: Add support for MT6873/8192") Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20230724154739.493724-1-nfraprado@collabora.comReviewed-by:
Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by:
-
Ricky Wu authored
rts5264 can support sd express card, so add the id in sd express card init to do rts5264 register setting when the sd express card insert Signed-off-by:
Ricky Wu <ricky_wu@realtek.com> Link: https://lore.kernel.org/r/20231208032145.2143580-4-ricky_wu@realtek.comSigned-off-by:
-
Ricky Wu authored
in order to support rts5264 in rtsx_pcr add the id in and determine whether the device is rts5264 to call rts5264 functions and do rts5264 workflows or set rts5264 registers Signed-off-by:
-
Ricky Wu authored
in order to support NEW chip rts5264, the definitions of some internal registers are define in new file rts5264.h, and some callback functions and the workflow for rts5264 are define in new file rts5264.c also add rts5264.o to Makefile Signed-off-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it was merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. CDX was fixed once, but commit ("cdx: Remove cdx controller list from cdx bus system") added another occurrence. Fixes: 54b406e1 ("cdx: Remove cdx controller list from cdx bus system") Signed-off-by:Rob Herring <robh@kernel.org> Acked-by:
Nikhil Agarwal <Nikhil.agarwal@amd.com> Link: https://lore.kernel.org/r/20231207163128.2707993-2-robh@kernel.orgSigned-off-by:
-
Lukas Bulwahn authored
Commit b9873755 ("misc: Add Nitro Secure Module driver") adds Nitro Security Module support, which selects the non-existing config CBOR. In the development of the commit, there was initially some code for CBOR independent of the driver, and the driver included this code with the line 'select CBOR'. This code for CBOR was later reduced to its bare minimum of functionality and included into the driver itself. The select CBOR remained unnoticed and was left behind without having any further purpose. Remove selecting the non-existing config CBOR. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Alexander Graf <graf@amazon.com> Link: https://lore.kernel.org/r/20231211074242.22999-1-lukas.bulwahn@gmail.comSigned-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 <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/09a89926787cb9f64caa73c510f04d9f04a5136f.1702051073.git.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:
-
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:
-
Dan Williams authored
Greg lamented: "Ick, sorry about that, obviously this test isn't actually built by any bots :(" A quick and dirty way to prevent this problem going forward is to always compile ndtest.ko whenever nfit_test is built. While this still does not expose the test code to any of the known build bots, it at least makes it the case that anyone that runs the x86 tests also compiles the powerpc test. I.e. the Intel NVDIMM maintainers are less likely to fall into this hole in the future. Link: http://lore.kernel.org/r/2023112729-aids-drainable-5744@gregkh Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Yi Zhang <yi.zhang@redhat.com> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Ira Weiny <ira.weiny@intel.com> Signed-off-by:Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Ira Weiny <ira.weiny@intel.com> Reviewed-by:
Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/170191437889.426826.15528612879942432918.stgit@dwillia2-xfh.jf.intel.comSigned-off-by:
-
Randy Dunlap authored
Correct function comments to prevent warnings from scripts/kernel-doc. mcb-core.c:270: warning: Function parameter or member 'carrier' not described in 'mcb_alloc_bus' mcb-core.c:336: warning: expecting prototype for mcb_bus_put(). Prototype was for mcb_bus_get() instead mcb-core.c:463: warning: Function parameter or member 'mem' not described in 'mcb_release_mem' mcb-core.c:463: warning: Excess function parameter 'dev' description in 'mcb_release_mem' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Johannes Thumshirn <morbidrsa@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20231206055821.17284-1-rdunlap@infradead.orgSigned-off-by:
-
Alice Ryhl authored
All of the other constants in this file are defined using enums, so make the constants more consistent by defining the ioctls in an enum as well. This is necessary for Rust Binder since the _IO macros are too complicated for bindgen to see that they expand to integer constants. Replacing the #defines with an enum forces bindgen to evaluate them properly, which allows us to access them from Rust. I originally intended to include this change in the first patch of the Rust Binder patchset [1], but at plumbers Carlos Llamas told me that this change has been discussed previously [2] and suggested that I send it upstream separately. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-1-08ba9197f637@google.com/ [1] Link: https://lore.kernel.org/all/YoIK2l6xbQMPGZHy@kroah.com/ [2] Signed-off-by:
Alice Ryhl <aliceryhl@google.com> Acked-by:
Carlos Llamas <cmllamas@google.com> Link: https://lore.kernel.org/r/20231208152801.3425772-1-aliceryhl@google.comSigned-off-by:
-
Arnd Bergmann authored
The dependencies in the mei framework are inconsistent, with some symbols using 'select INTEL_MEI' to force it being enabled and others using 'depends on INTEL_MEI'. In general, one should not select user-visible symbols, so change all of these to normal dependencies, but change the default on INTEL_MEI to be enabled when building a kernel for an Intel CPU with ME or a generic x86 kernel. Having consistent dependencies makes the 'menuconfig' listing more readable by using proper indentation. A large if/endif block is just a simpler syntax than repeating the dependencies for each symbol. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Wentong Wu <wentong.wu@intel.com> Link: https://lore.kernel.org/r/20231214183946.109124-2-arnd@kernel.orgSigned-off-by:
-
Arnd Bergmann authored
CONFIG_INTEL_MEI_VSC_HW can be set to built-in even with CONFIG_MEI=m, but then the driver is not built because Kbuild never enters the drivers/misc/mei directory for built-in files, leading to a link failure: ERROR: modpost: "vsc_tp_reset" [drivers/misc/mei/mei-vsc.ko] undefined! ERROR: modpost: "vsc_tp_init" [drivers/misc/mei/mei-vsc.ko] undefined! ERROR: modpost: "vsc_tp_xfer" [drivers/misc/mei/mei-vsc.ko] undefined! ERROR: modpost: "vsc_tp_need_read" [drivers/misc/mei/mei-vsc.ko] undefined! ERROR: modpost: "vsc_tp_intr_enable" [drivers/misc/mei/mei-vsc.ko] undefined! ERROR: modpost: "vsc_tp_intr_synchronize" [drivers/misc/mei/mei-vsc.ko] undefined! ERROR: modpost: "vsc_tp_intr_disable" [drivers/misc/mei/mei-vsc.ko] undefined! ERROR: modpost: "vsc_tp_register_event_cb" [drivers/misc/mei/mei-vsc.ko] undefined! Add an explicit dependency on CONFIG_MEI that was apparently missing, to ensure the VSC_HW driver cannot be built-in with MEI itself being a loadable module. Fixes: 566f5ca9 ("mei: Add transport driver for IVSC device") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
-
Sakari Ailus authored
Rework firmware image names with the users in mind---there's no need for variation between firmware names, apart from connected sensors. All supported SoCs use the same firmware, too. Use a single set of firmware binaries and assume they'll be found under intel/vsc directory. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231213094055.446611-1-sakari.ailus@linux.intel.comSigned-off-by:
-
Alexander Usyskin authored
Remove stray empty line at the beginning of the file to have SPDX header t the first line. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Link: https://lore.kernel.org/r/20231214143752.294008-1-tomas.winkler@intel.comSigned-off-by:
-
Randy Dunlap authored
For include/uapi/linux/mei.h, correct spellos reported by codespell. Signed-off-by:
-
Patrick Delaunay authored
On STM32MP25, OTP area may be read/written by using BSEC (boot, security and OTP control). The BSEC internal peripheral is only managed by the secure world. The 12 Kbits of OTP (effective) are organized into the following regions: - lower OTP (OTP0 to OTP127) = 4096 lower OTP bits, bitwise (1-bit) programmable - mid OTP (OTP128 to OTP255) = 4096 middle OTP bits, bulk (32-bit) programmable - upper OTP (OTP256 to OTP383) = 4096 upper OTP bits, bulk (32-bit) programmable, only accessible when BSEC is in closed state. As HWKEY and ECIES key are only accessible by ROM code; only 368 OTP words are managed in this driver (OTP0 to OTP267). This patch adds the STM32MP25 configuration for reading and writing the OTP data using the OP-TEE BSEC TA services. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-11-srinivas.kandagatla@linaro.orgSigned-off-by:
-
Patrick Delaunay authored
Add a new compatible for stm32mp25 support. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Miquel Raynal authored
The binary content of nvmem devices is available to the user so in the easiest cases, finding the content of a cell is rather easy as it is just a matter of looking at a known and fixed offset. However, nvmem layouts have been recently introduced to cope with more advanced situations, where the offset and size of the cells is not known in advance or is dynamic. When using layouts, more advanced parsers are used by the kernel in order to give direct access to the content of each cell, regardless of its position/size in the underlying device. Unfortunately, these information are not accessible by users, unless by fully re-implementing the parser logic in userland. Let's expose the cells and their content through sysfs to avoid these situations. Of course the relevant NVMEM sysfs Kconfig option must be enabled for this support to be available. Not all nvmem devices expose cells. Indeed, the .bin_attrs attribute group member will be filled at runtime only when relevant and will remain empty otherwise. In this case, as the cells attribute group will be empty, it will not lead to any additional folder/file creation. Exposed cells are read-only. There is, in practice, everything in the core to support a write path, but as I don't see any need for that, I prefer to keep the interface simple (and probably safer). The interface is documented as being in the "testing" state which means we can later add a write attribute if though relevant. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Tested-by:
Rafał Miłecki <rafal@milecki.pl> Tested-by:
-
Miquel Raynal authored
The binary content of nvmem devices is available to the user so in the easiest cases, finding the content of a cell is rather easy as it is just a matter of looking at a known and fixed offset. However, nvmem layouts have been recently introduced to cope with more advanced situations, where the offset and size of the cells is not known in advance or is dynamic. When using layouts, more advanced parsers are used by the kernel in order to give direct access to the content of each cell regardless of their position/size in the underlying device, but these information were not accessible to the user. By exposing the nvmem cells to the user through a dedicated cell/ folder containing one file per cell, we provide a straightforward access to useful user information without the need for re-writing a userland parser. Content of nvmem cells is usually: product names, manufacturing date, MAC addresses, etc, Signed-off-by:
-
Miquel Raynal authored
Current layout support was initially written without modules support in mind. When the requirement for module support rose, the existing base was improved to adopt modularization support, but kind of a design flaw was introduced. With the existing implementation, when a storage device registers into NVMEM, the core tries to hook a layout (if any) and populates its cells immediately. This means, if the hardware description expects a layout to be hooked up, but no driver was provided for that, the storage medium will fail to probe and try later from scratch. Even if we consider that the hardware description shall be correct, we could still probe the storage device (especially if it contains the rootfs). One way to overcome this situation is to consider the layouts as devices, and leverage the native notifier mechanism. When a new NVMEM device is registered, we can populate its nvmem-layout child, if any, and wait for the matching to be done in order to get the cells (the waiting can be easily done with the NVMEM notifiers). If the layout driver is compiled as a module, it should automatically be loaded. This way, there is no strong order to enforce, any NVMEM device creation or NVMEM layout driver insertion will be observed as a new event which may lead to the creation of additional cells, without disturbing the probes with costly (and sometimes endless) deferrals. In order to achieve that goal we create a new bus for the nvmem-layouts with minimal logic to match nvmem-layout devices with nvmem-layout drivers. All this infrastructure code is created in the layouts.c file. Signed-off-by:
-
