- 19 Dec, 2023 2 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'extcon-next-for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next Chanwoo writes: Update extcon next for v6.8 Detailed description for this pull request: 1. Fix possible memory leak of device name in extcon_dev_register() : Fix memory leak on error path of extcon_dev_register(). 2. Set interrupt polarity based on device-tree for extcon-usbc-tusb320.c :Remove 'IRQF_TRIGGER_FALLING' request which is not allowed on every interrupt controller (i.e. arm64 GIC). Replace flag by a request that depends on the actual device-tree setting. 3. Fix the comment style according to guide on extcon-qcom-spmi-misc.c. * tag 'extcon-next-for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon: extcon: qcom-spmi-misc: don't use kernel-doc marker for comment extcon: usbc-tusb320: Set interrupt polarity based on device-tree extcon: fix possible name leak in extcon_dev_register()
-
Greg Kroah-Hartman authored
Merge tag 'mhi-for-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi into char-misc-next Manivannan writes: MHI Host ======== - Added alignment check for event ring read pointer to avoid the potential buffer corruption issue. - Added support for SDX75 modem which takes longer time to enter READY state. - Added spinlock to protect concurrent access while queuing transfer ring elements. - Dropped the read channel lock before invoking the client callback as the client can potentially queue buffers thus ending up wtih soft lockup. MHI Endpoint ============ - Used kzalloc() to allocate event ring elements instead of allocating the elements on the stack, as the endpoint controller trying to queue them may not be able to use vmalloc memory (using DMA). - Used slab allocator for allocting the memory for objects used frequently and are of fixed size. - Added support for interrupt moderation timer feature which is used by the host to limit the number of interrupts raised by the device for an event ring. - Added async read/write DMA support for transferring data between host and the endpoint. So far MHI EP stack assumed that the data will be transferred synchronously (i.e., it sends completion once the transfer APIs are returned). But this impacts the throughput if the controller is using DMA to do the transfer. So to add async suport, existing sync transfer APIs are renamed to {read/write}_sync and also introduced two new APIs {read/write}_async for carrying out the async transfer. Controllers implementing the async APIs should queue the buffers and return immediately without waiting for transfer completion. Once the transfer completion happens later, they should invoke the completion callback so that the MHI EP stack can send the completion event to the host. The controller driver patches (PCI EPF) for this async support are also merged to the MHI tree with Acks from PCI maintainers. - Fixed the DMA channel direction in error path of the PCI EPF driver. * tag 'mhi-for-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi: bus: mhi: host: Drop chan lock before queuing buffers bus: mhi: host: Add spinlock to protect WP access when queueing TREs PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single() bus: mhi: ep: Add checks for read/write callbacks while registering controllers bus: mhi: ep: Add support for async DMA read operation bus: mhi: ep: Add support for async DMA write operation PCI: epf-mhi: Enable MHI async read/write support PCI: epf-mhi: Add support for DMA async read/write operation PCI: epf-mhi: Simulate async read/write using iATU bus: mhi: ep: Introduce async read/write callbacks bus: mhi: ep: Rename read_from_host() and write_to_host() APIs bus: mhi: ep: Pass mhi_ep_buf_info struct to read/write APIs bus: mhi: ep: Add support for interrupt moderation timer bus: mhi: ep: Use slab allocator where applicable bus: mhi: host: Add alignment check for event ring read pointer bus: mhi: host: pci_generic: Add SDX75 based modem support bus: mhi: host: Add a separate timeout parameter for waiting ready bus: mhi: ep: Do not allocate event ring element on stack
-
- 18 Dec, 2023 1 commit
-
-
Greg Kroah-Hartman authored
Merge tag 'fpga-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga into char-misc-next Xu writes: FPGA Manager changes for 6.8-rc1 DFL: - Philipp's change uses memdup_array_user() to do better overflow check All patches have been reviewed on the mailing list, and have been in the last linux-next releases (as part of our for-next branch). Signed-off-by:
Xu Yilun <yilun.xu@intel.com> * tag 'fpga-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga: drivers/fpga: use standard array-copy function
-
- 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>
-
- 16 Dec, 2023 2 commits
-
-
Qiang Yu authored
Ensure read and write locks for the channel are not taken in succession by dropping the read lock from parse_xfer_event() such that a callback given to client can potentially queue buffers and acquire the write lock in that process. Any queueing of buffers should be done without channel read lock acquired as it can result in multiple locks and a soft lockup. Cc: <stable@vger.kernel.org> # 5.7 Fixes: 1d3173a3 ("bus: mhi: core: Add support for processing events from client device") Signed-off-by:
Qiang Yu <quic_qianyu@quicinc.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Tested-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/1702276972-41296-3-git-send-email-quic_qianyu@quicinc.com [mani: added fixes tag and cc'ed stable] Signed-off-by:
-
Bhaumik Bhatt authored
Protect WP accesses such that multiple threads queueing buffers for incoming data do not race. Meanwhile, if CONFIG_TRACE_IRQFLAGS is enabled, irq will be enabled once __local_bh_enable_ip is called as part of write_unlock_bh. Hence, let's take irqsave lock after TRE is generated to avoid running write_unlock_bh when irqsave lock is held. Cc: stable@vger.kernel.org Fixes: 189ff97c ("bus: mhi: core: Add support for data transfer") Signed-off-by:
Bhaumik Bhatt <bbhatt@codeaurora.org> Signed-off-by:
-
- 15 Dec, 2023 34 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:
-
