summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-01-13Merge branch 'mlx5-hw-managed-flow-steering-in-fs-core-level'Jakub Kicinski
Tariq Toukan says: ==================== mlx5 HW-Managed Flow Steering in FS core level This patchset by Moshe follows Yevgeny's patchsets [1][2] on subject "HW-Managed Flow Steering in mlx5 driver". As introduced there in HW managed Flow Steering mode (HWS) the driver is configuring steering rules directly to the HW using WQs with a special new type of WQE (Work Queue Element). This way we can reach higher rule insertion/deletion rate with much lower CPU utilization compared to SW Managed Flow Steering (SWS). This patchset adds API to manage namespace, flow tables, flow groups and prepare FTE (Flow Table Entry) rules. It also adds caching and pool mechanisms for HWS actions to allow sharing of steering actions among different rules. The implementation of this API in FS layer, allows FS core to use HW Managed Flow Steering in addition to the existing FW or SW Managed Flow Steering. Patch 13 of this series adds support for configuring HW Managed Flow Steering mode through devlink param, similar to configuring SW Managed Flow Steering mode: # devlink dev param set pci/0000:08:00.0 name flow_steering_mode \ cmode runtime value hmfs In addition, the series contains 2 HWS patches from Yevgeny that implement flow update support. [1] https://lore.kernel.org/netdev/20240903031948.78006-1-saeed@kernel.org/ [2] https://lore.kernel.org/all/20250102181415.1477316-1-tariqt@nvidia.com/ ==================== Link: https://patch.msgid.link/20250109160546.1733647-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: HWS, update flow - support through bigger action RTCYevgeny Kliteynik
This patch is the second part of update flow implementation. Instead of using two action RTCs, we use the same RTC which is twice the size of what was required before the update flow support. This way we always allocate STEs from the same RTC (same pool), which means that update is done similar to how create is done. The bigger size allows us to allocate and write new STEs, and later free the old (pre-update) STEs. Similar to rule creation, STEs are written in reverse order: - write action STEs, while match STE is still pointing to the old action STEs - overwrite the match STE with the new one, which now is pointing to the new action STEs Old action STEs can be freed only once we got completion on the writing of the new match STE. To implement this we added new rule states: UPDATING/UPDATED. Rule is moved to UPDATING state in the beginning of the update flow. Once all completions are received, rule is moved to UPDATED state. At this point old action STEs are freed and rule goes back to CREATED state. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-16-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: HWS, update flow - remove the use of dual RTCsYevgeny Kliteynik
This patch is the first part of update flow implementation. Update flow should support rules with single STE (match STE only), as well as rules with multiple STEs (match STE plus action STEs). Supporting the rules with single STE is straightforward: we just overwrite the STE, which is an atomic operation. Supporting the rules with action STEs is a more complicated case. The existing implementation uses two action RTCs per matcher and alternates between the two for each update request. This implementation was unnecessarily complex and lead to some unhandled edge cases, so the support for rule update with multiple STEs wasn't really functional. This patch removes this code, and the next patch adds implementation of a different approach. Note that after applying this patch and before applying the next patch we still have support for update rule with single STE (only match STE w/o action STEs), but update will fail for rules with action STEs. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-15-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add HWS to steering mode optionsMoshe Shemesh
Add HW Steering mode to mlx5 devlink param of steering mode options. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-14-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add HWS get capabilitiesMoshe Shemesh
Add API function get capabilities to HW Steering flow commands. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-13-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, set create match definer to not supported by HWSMoshe Shemesh
Currently HW Steering does not support the API functions of create and destroy match definer. Return not supported error in case requested. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-12-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add support for dest vport HWS actionMoshe Shemesh
Add support for HW Steering action of vport destination. Add dest vport actions cache. Hold action in cache per vport / vport and vhca_id. Add action to cache on demand and remove on namespace closure to reduce actions creation and destroy. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-11-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add HWS fte API functionsMoshe Shemesh
Add create, destroy and update fte API functions for adding, removing and updating flow steering rules in HW Steering mode. Get HWS actions according to required rule, use actions from pool whenever possible. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-10-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add dest table cacheMoshe Shemesh
Add cache of destination flow table HWS action per HWS table. For each flow table created cache a destination action towards this table. The cached action will be used on the downstream patch whenever a rule requires such action. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-9-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, manage flow counters HWS action sharing by refcountMoshe Shemesh
Multiple flow counters can utilize a single Hardware Steering (HWS) action for Hardware Steering rules. Given that these counter bulks are not exclusively created for Hardware Steering, but also serve purposes such as statistics gathering and other steering modes, it's more efficient to create the HWS action only when it's first needed by a Hardware Steering rule. This approach allows for better resource management through the use of a reference count, rather than automatically creating an HWS action for every bulk of flow counters. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-8-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add HWS modify header API functionMoshe Shemesh
Add modify header alloc and dealloc API functions to provide modify header actions for steering rules. Use fs hws pools to get actions from shared bulks of modify header actions. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add HWS packet reformat API functionMoshe Shemesh
Add packet reformat alloc and dealloc API functions to provide packet reformat actions for steering rules. Add HWS action pools for each of the following packet reformat types: - decapl3: decapsulate l3 tunnel to l2 - encapl2: encapsulate l2 to tunnel l2 - encapl3: encapsulate l2 to tunnel l3 - insert_hdr: insert header In addition cache remove header action for remove vlan header as this is currently the only use case of remove header action in the driver. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-6-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add HWS actions poolMoshe Shemesh
The HW Steering actions pool will help utilize the option in HW Steering to share steering actions among different rules. Create pool on root namespace creation and add few HW Steering actions that don't depend on the steering rule itself and thus can be shared between rules, created on same namespace: tag, pop_vlan, push_vlan, drop, decap l2. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-5-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add HWS flow group API functionsMoshe Shemesh
Add API functions to create and destroy HW Steering flow groups. Each flow group consists of a Backward Compatible (BWC) HW Steering matcher which holds the flow group match criteria. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-4-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add HWS flow table API functionsMoshe Shemesh
Add API functions to create, modify and destroy HW Steering flow tables. Modify table enables change, connect or disconnect default miss table. Add update root flow table API function. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-3-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/mlx5: fs, add HWS root namespace functionsMoshe Shemesh
Add flow steering commands structure for HW steering. Implement create, destroy and set peer HW steering root namespace functions. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20250109160546.1733647-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13eth: iavf: extend the netdev_lock usageJakub Kicinski
iavf uses the netdev->lock already to protect shapers. In an upcoming series we'll try to protect NAPI instances with netdev->lock. We need to modify the protection a bit. All NAPI related calls in the driver need to be consistently under the lock. This will allow us to easily switch to a "we already hold the lock" NAPI API later. register_netdevice(), OTOH, must not be called under the netdev_lock() as we do not intend to have an "already locked" version of this call. Link: https://patch.msgid.link/20250111071339.3709071-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net: cleanup init_dummy_netdev_core()Jakub Kicinski
init_dummy_netdev_core() used to cater to net_devices which did not come from alloc_netdev_mqs(). Since that's no longer supported remove the init logic which duplicates alloc_netdev_mqs(). While at it rename back to init_dummy_netdev(). Reviewed-by: Joe Damato <jdamato@fastly.com> Link: https://patch.msgid.link/20250113003456.3904110-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net: remove init_dummy_netdev()Jakub Kicinski
init_dummy_netdev() can initialize statically declared or embedded net_devices. Such netdevs did not come from alloc_netdev_mqs(). After recent work by Breno, there are the only two cases where we have do that. Switch those cases to alloc_netdev_mqs() and delete init_dummy_netdev(). Dealing with static netdevs is not worth the maintenance burden. Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by: Joe Damato <jdamato@fastly.com> Link: https://patch.msgid.link/20250113003456.3904110-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13tools/net/ynl: ethtool: support spec load from install locationDonald Hunter
Replace hard-coded paths for spec and schema with lookup functions so that ethtool.py will work in-tree or when installed. Signed-off-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250111154803.7496-2-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13tools/net/ynl: add support for --family and --list-familiesDonald Hunter
Add a --family option to ynl to specify the spec by family name instead of file path, with support for searching in-tree and system install location and a --list-families option to show the available families. ./tools/net/ynl/pyynl/cli.py --family rt_addr --dump getaddr Signed-off-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250111154803.7496-1-donald.hunter@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13can: grcan: move napi_enable() from under spin lockJakub Kicinski
I don't see any reason why napi_enable() needs to be under the lock, only reason I could think of is if the IRQ also took this lock but it doesn't. napi_enable() will soon need to sleep. Acked-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Reviewed-by: Francois Romieu <romieu@fr.zoreil.com> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://patch.msgid.link/20250111024742.3680902-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net: stmmac: sti: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr()Raphael Gallais-Pou
Letting the compiler remove these functions when the kernel is built without CONFIG_PM_SLEEP support is simpler and less error prone than the use of #ifdef based kernel configuration guards. Signed-off-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Yanteng Si <si.yanteng@linux.dev> Link: https://patch.msgid.link/20250109155842.60798-1-rgallaispou@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/ncsi: fix locking in Get MAC Address handlingPaul Fertser
Obtaining RTNL lock in a response handler is not allowed since it runs in an atomic softirq context. Postpone setting the MAC address by adding a dedicated step to the configuration FSM. Fixes: 790071347a0a ("net/ncsi: change from ndo_set_mac_address to dev_set_mac_address") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/20241129-potin-revert-ncsi-set-mac-addr-v1-1-94ea2cb596af@gmail.com Signed-off-by: Paul Fertser <fercerpav@gmail.com> Tested-by: Potin Lai <potin.lai.pt@gmail.com> Link: https://patch.msgid.link/20250109145054.30925-1-fercerpav@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13net/smc: fix data error when recvmsg with MSG_PEEK flagGuangguan Wang
When recvmsg with MSG_PEEK flag, the data will be copied to user's buffer without advancing consume cursor and without reducing the length of rx available data. Once the expected peek length is larger than the value of bytes_to_rcv, in the loop of do while in smc_rx_recvmsg, the first loop will copy bytes_to_rcv bytes of data from the position local_tx_ctrl.cons, the second loop will copy the min(bytes_to_rcv, read_remaining) bytes from the position local_tx_ctrl.cons again because of the lacking of process with advancing consume cursor and reducing the length of available data. So do the subsequent loops. The data copied in the second loop and the subsequent loops will result in data error, as it should not be copied if no more data arrives and it should be copied from the position advancing bytes_to_rcv bytes from the local_tx_ctrl.cons if more data arrives. This issue can be reproduce by the following python script: server.py: import socket import time server_ip = '0.0.0.0' server_port = 12346 server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.bind((server_ip, server_port)) server_socket.listen(1) print('Server is running and listening for connections...') conn, addr = server_socket.accept() print('Connected by', addr) while True: data = conn.recv(1024) if not data: break print('Received request:', data.decode()) conn.sendall(b'Hello, client!\n') time.sleep(5) conn.sendall(b'Hello, again!\n') conn.close() client.py: import socket server_ip = '<server ip>' server_port = 12346 resp=b'Hello, client!\nHello, again!\n' client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client_socket.connect((server_ip, server_port)) request = 'Hello, server!' client_socket.sendall(request.encode()) peek_data = client_socket.recv(len(resp), socket.MSG_PEEK | socket.MSG_WAITALL) print('Peeked data:', peek_data.decode()) client_socket.close() Fixes: 952310ccf2d8 ("smc: receive data from RMBE") Reported-by: D. Wythe <alibuda@linux.alibaba.com> Signed-off-by: Guangguan Wang <guangguan.wang@linux.alibaba.com> Link: https://patch.msgid.link/20250104143201.35529-1-guangguan.wang@linux.alibaba.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-01-13of: Warn when of_property_read_bool() is used on non-boolean propertiesRob Herring (Arm)
The use of of_property_read_bool() for non-boolean properties is deprecated. The primary use of it was to test property presence, but that has been replaced in favor of of_property_present(). With those uses now fixed, add a warning to discourage new ones. Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20250109-dt-type-warnings-v1-2-0150e32e716c@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-13device property: Split property reading bool and presence test opsRob Herring (Arm)
The fwnode/device property API currently implement (fwnode|device)_property_read_bool() with (fwnode|device)_property_present(). That does not allow having different behavior depending on the backend. Specifically, the usage of (fwnode|device)_property_read_bool() on non-boolean properties is deprecated on DT. In order to add a warning on this deprecated use, these 2 APIs need separate ops for the backend. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/20250109-dt-type-warnings-v1-1-0150e32e716c@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-13of/fdt: Check fdt_get_mem_rsv() error in early_init_fdt_scan_reserved_mem()Zijun Hu
early_init_fdt_scan_reserved_mem() invoks fdt_get_mem_rsv(), and it will use uninitialized variables @base and @size once the callee suffers error. Fix by checking fdt_get_mem_rsv() error as other callers do. Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250109-of_core_fix-v4-13-db8a72415b8c@quicinc.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-13of: reserved-memory: Move an assignment to effective place in ↵Zijun Hu
__reserved_mem_alloc_size() The assignment '@base = 0' in __reserved_mem_alloc_size() is meaningless since @base was already initialized to 0. Move the assignment to effective and proper place. Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250109-of_core_fix-v4-12-db8a72415b8c@quicinc.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-13of: reserved-memory: Do not make kmemleak ignore freed addressZijun Hu
early_init_dt_alloc_reserved_memory_arch() will free address @base when suffers memblock_mark_nomap() error, but it still makes kmemleak ignore the freed address @base via kmemleak_ignore_phys(). That is unnecessary, besides, also causes unnecessary warning messages: kmemleak_ignore_phys() -> make_black_object() -> paint_ptr() -> kmemleak_warn() // warning message here. Fix by avoiding kmemleak_ignore_phys() when suffer the error. Fixes: 658aafc8139c ("memblock: exclude MEMBLOCK_NOMAP regions from kmemleak") Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250109-of_core_fix-v4-10-db8a72415b8c@quicinc.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-13of: reserved-memory: Fix using wrong number of cells to get property 'alignment'Zijun Hu
According to DT spec, size of property 'alignment' is based on parent node’s #size-cells property. But __reserved_mem_alloc_size() wrongly uses @dt_root_addr_cells to get the property obviously. Fix by using @dt_root_size_cells instead of @dt_root_addr_cells. Fixes: 3f0c82066448 ("drivers: of: add initialization code for dynamic reserved memory") Cc: stable@vger.kernel.org Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20250109-of_core_fix-v4-9-db8a72415b8c@quicinc.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-01-13clk: en7523: Add clock for eMMC for EN7581Christian Marangi
Add clock for eMMC for EN7581. This is used to give info of the current eMMC source clock and to switch it from 200MHz or 150MHz. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20250113231030.6735-5-ansuelsmth@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-01-13dt-bindings: clock: add ID for eMMC for EN7581Christian Marangi
Add ID for eMMC for EN7581. This is to control clock selection of eMMC between 200MHz and 150MHz. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250113231030.6735-4-ansuelsmth@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-01-13dt-bindings: clock: drop NUM_CLOCKS define for EN7581Christian Marangi
Drop NUM_CLOCKS define for EN7581 include. This is not a binding and should not be placed here. Value is derived internally in the user driver. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250113231030.6735-3-ansuelsmth@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-01-13clk: en7523: Rework clock handling for different clock numbersChristian Marangi
Airoha EN7581 SoC have additional clock compared to EN7523 but current driver permits to only support up to EN7523 clock numbers. To handle this, rework the clock handling and permit to declare the clocks number in match_data and alloca clk_data based on the compatible match_data. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20250113231030.6735-2-ansuelsmth@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2025-01-13Merge tag 'nolibc-20250113-for-6.14-1' of ↵Shuah Khan
https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc into nolibc nolibc changes for 6.14 Changes ------- * Test riscv32 support * Print an error message if toolchain for run-tests.sh is missing
2025-01-13pm: cpupower: Add missing residency header changes in cpuidle.h to SWIGJohn B. Wyatt IV
"tools/cpupower: display residency value in idle-info" added a new function to cpuidle.h. This patch adds them to the bindings. Link: https://lore.kernel.org/linux-pm/20240809083728.266697-1-aboorvad@linux.ibm.com/ Tested by compiling both libcpupower and the headers; running the test script that does not use the functions as a basic sanity test. Link: https://lore.kernel.org/r/20250108221852.30771-1-jwyatt@redhat.com Signed-off-by: "John B. Wyatt IV" <jwyatt@redhat.com> Signed-off-by: "John B. Wyatt IV" <sageofredondo@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2025-01-13rust: uaccess: generalize userSliceReader to support any VecFilipe Xavier
The UserSliceReader::read_all function is currently restricted to use only Vec with the kmalloc allocator. However, there is no reason for this limitation. This patch generalizes the function to accept any Vec regardless of the allocator used. There's a use-case for a KVVec in Binder to avoid maximum sizes for a certain array. Link: https://github.com/Rust-for-Linux/linux/issues/1136 Signed-off-by: Filipe Xavier <felipeaggger@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20250107-gen-userslice-readall-alloc-v2-1-d7fe4d19241a@gmail.com [ Reflowed and slightly reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: kernel: add improved version of `ForeignOwnable::borrow_mut`Alice Ryhl
Previously, the `ForeignOwnable` trait had a method called `borrow_mut` that was intended to provide mutable access to the inner value. However, the method accidentally made it possible to change the address of the object being modified, which usually isn't what we want. (And when we want that, it can be done by calling `from_foreign` and `into_foreign`, like how the old `borrow_mut` was implemented.) In this patch, we introduce an alternate definition of `borrow_mut` that solves the previous problem. Conceptually, given a pointer type `P` that implements `ForeignOwnable`, the `borrow_mut` method gives you the same kind of access as an `&mut P` would, except that it does not let you change the pointer `P` itself. This is analogous to how the existing `borrow` method provides the same kind of access to the inner value as an `&P`. Note that for types like `Arc`, having an `&mut Arc<T>` only gives you immutable access to the inner `T`. This is because mutable references assume exclusive access, but there might be other handles to the same reference counted value, so the access isn't exclusive. The `Arc` type implements this by making `borrow_mut` return the same type as `borrow`. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241120-borrow-mut-v6-6-80dbadd00951@gmail.com [ Updated to `crate::ffi::`. Reworded title slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: kernel: reorder `ForeignOwnable` itemsTamir Duberstein
`{into,from}_foreign` before `borrow` is slightly more logical. This removes an inconsistency with `kbox.rs` which already uses this ordering. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Link: https://lore.kernel.org/r/20241120-borrow-mut-v6-5-80dbadd00951@gmail.com [ Reworded title slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: kernel: change `ForeignOwnable` pointer to mutTamir Duberstein
It is slightly more convenient to operate on mut pointers, and this also properly conveys the desired ownership semantics of the trait. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241120-borrow-mut-v6-4-80dbadd00951@gmail.com [ Reworded title slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: arc: split unsafe block, add missing commentTamir Duberstein
The new SAFETY comment style is taken from existing comments in `deref` and `drop. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Link: https://lore.kernel.org/r/20241120-borrow-mut-v6-3-80dbadd00951@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: types: avoid `as` castsTamir Duberstein
Replace `as` casts with `cast{,_mut}` calls which are a bit safer. In one instance, remove an unnecessary `as` cast without replacement. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241120-borrow-mut-v6-2-80dbadd00951@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: arc: use `NonNull::new_unchecked`Tamir Duberstein
There is no need to check (and panic on violations of) the safety requirements on `ForeignOwnable` functions. Avoiding the check is consistent with the implementation of `ForeignOwnable` for `Box`. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Link: https://lore.kernel.org/r/20241120-borrow-mut-v6-1-80dbadd00951@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: use derive(CoercePointee) on rustc >= 1.84.0Xiangfei Ding
The `kernel` crate relies on both `coerce_unsized` and `dispatch_from_dyn` unstable features. Alice Ryhl has proposed [1] the introduction of the unstable macro `SmartPointer` to reduce such dependence, along with a RFC patch [2]. Since Rust 1.81.0 this macro, later renamed to `CoercePointee` in Rust 1.84.0 [3], has been fully implemented with the naming discussion resolved. This feature is now on track to stabilization in the language. In order to do so, we shall start using this macro in the `kernel` crate to prove the functionality and utility of the macro as the justification of its stabilization. This patch makes this switch in such a way that the crate remains backward compatible with older Rust compiler versions, via the new Kconfig option `RUSTC_HAS_COERCE_POINTEE`. A minimal demonstration example is added to the `samples/rust/rust_print_main.rs` module. Link: https://rust-lang.github.io/rfcs/3621-derive-smart-pointer.html [1] Link: https://lore.kernel.org/all/20240823-derive-smart-pointer-v1-1-53769cd37239@google.com/ [2] Link: https://github.com/rust-lang/rust/pull/131284 [3] Signed-off-by: Xiangfei Ding <dingxiangfei2009@gmail.com> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241203205050.679106-2-dingxiangfei2009@gmail.com [ Fixed version to 1.84. Renamed option to `RUSTC_HAS_COERCE_POINTEE` to match `CC_HAS_*` ones. Moved up new config option, closer to the `CC_HAS_*` ones. Simplified Kconfig line. Fixed typos and slightly reworded example and commit. Added Link to PR. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: alloc: add doctest for `ArrayLayout::new()`Jimmy Ostler
Add a rustdoc example and Kunit test to the `ArrayLayout` struct's `ArrayLayout::new()` function. This patch depends on the first patch in this series in order for the KUnit test to compile. Suggested-by: Boqun Feng <boqun.feng@gmail.com> Link: https://github.com/Rust-for-Linux/linux/issues/1131 Reviewed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Jimmy Ostler <jtostler1@gmail.com> Link: https://lore.kernel.org/r/f1564da5bcaa6be87aee312767a1d1694a03d1b7.1734674670.git.jtostler1@gmail.com [ Added periods to example comments. Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: init: update `stack_try_pin_init` examplesJimmy Ostler
Change documentation imports to use `kernel::alloc::AllocError`, because `KBox::new()` now returns that, instead of the `core`'s `AllocError`. Reviewed-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Jimmy Ostler <jtostler1@gmail.com> Link: https://lore.kernel.org/r/ec8badbe94c5e78f22315325a7f2ae96129d6a65.1734674670.git.jtostler1@gmail.com [ Fixed formatting of imports (still unordered). Slightly reworded commit. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: error: import `kernel`'s `LayoutError` instead of `core`'sJimmy Ostler
Import the internal (`kernel::alloc`) version of `LayoutError` instead of the `core::alloc` one. In particular, this results in switching the type in the existing `From<LayoutError> for Error` implementation. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Jimmy Ostler <jtostler1@gmail.com> Link: https://lore.kernel.org/r/fe58a02189e8804a9eabdd01cb1927d4c491d79c.1734674670.git.jtostler1@gmail.com [ Reworded commit. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: str: replace unwraps with question mark operatorsDaniel Sedlak
Simplify the error handling by replacing unwraps with the question mark operator. Furthermore, unwraps can convey a wrong impression that unwrapping is fine in general, thus this patch removes this unwrapping. Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/rust-for-linux/CANiq72nsK1D4NuQ1U7NqMWoYjXkqQSj4QuUEL98OmFbq022Z9A@mail.gmail.com/ Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Daniel Sedlak <daniel@sedlak.dev> Link: https://lore.kernel.org/r/20241123095033.41240-5-daniel@sedlak.dev [ Slightly reworded commit. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-13rust: page: remove unnecessary helper function from doctestDaniel Sedlak
Doctests in `page.rs` contained a helper function `dox` which acted as a wrapper for using the `?` operator. However, this is not needed because doctests are implicitly wrapped in function see [1]. Link: https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html#using--in-doc-tests [1] Suggested-by: Dirk Behme <dirk.behme@de.bosch.com> Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://lore.kernel.org/rust-for-linux/459782fe-afca-4fe6-8ffb-ba7c7886de0a@de.bosch.com/ Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Signed-off-by: Daniel Sedlak <daniel@sedlak.dev> Link: https://lore.kernel.org/r/20241123095033.41240-4-daniel@sedlak.dev [ Fixed typo in SoB. Slightly reworded commit. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-16 22:26:51 +0000