summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* net: micrel: Add PHC support for lan8841Horatiu Vultur2023-02-131-24/+599
| | | | | | | | | Add support for PHC and timestamping operations for the lan8841 PHY. PTP 1-step and 2-step modes are supported, over Ethernet and UDP both ipv4 and ipv6. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'devlink-params-cleanup'David S. Miller2023-02-135-66/+91
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jiri Pirko says: ==================== devlink: params cleanups and devl_param_driverinit_value_get() fix The primary motivation of this patchset is the patch #6, which fixes an issue introduced by 075935f0ae0f ("devlink: protect devlink param list by instance lock") and reported by Kim Phillips <kim.phillips@amd.com> (https://lore.kernel.org/netdev/719de4f0-76ac-e8b9-38a9-167ae239efc7@amd.com/) and my colleagues doing mlx5 driver regression testing. The basis idea is that devl_param_driverinit_value_get() could be possible to the called without holding devlink intance lock in most of the cases (all existing ones in the current codebase), which would fix some mlx5 flows where the lock is not held. To achieve that, make sure that the param value does not change between reloads with patch #2. Also, convert the param list to xarray which removes the worry about list_head consistency when doing lockless lookup. The rest of the patches are doing some small related cleanup of things that poke me in the eye during the work. --- v1->v2: - a small bug was fixed in patch #2, the rest of the code stays the same so I left review/ack tags attached to them ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * devlink: add forgotten devlink instance lock assertion to ↵Jiri Pirko2023-02-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | devl_param_driverinit_value_set() Driver calling devl_param_driverinit_value_set() has to hold devlink instance lock while doing that. Put an assertion there. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * devlink: allow to call devl_param_driverinit_value_get() without holding ↵Jiri Pirko2023-02-131-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instance lock If the driver maintains following basic sane behavior, the devl_param_driverinit_value_get() function could be called without holding instance lock: 1) Driver ensures a call to devl_param_driverinit_value_get() cannot race with registering/unregistering the parameter with the same parameter ID. 2) Driver ensures a call to devl_param_driverinit_value_get() cannot race with devl_param_driverinit_value_set() call with the same parameter ID. 3) Driver ensures a call to devl_param_driverinit_value_get() cannot race with reload operation. By the nature of params usage, these requirements should be trivially achievable. If the driver for some off reason is not able to comply, it has to take the devlink->lock while calling devl_param_driverinit_value_get(). Remove the lock assertion and add comment describing the locking requirements. This fixes a splat in mlx5 driver introduced by the commit referenced in the "Fixes" tag. Lore: https://lore.kernel.org/netdev/719de4f0-76ac-e8b9-38a9-167ae239efc7@amd.com/ Reported-by: Kim Phillips <kim.phillips@amd.com> Fixes: 075935f0ae0f ("devlink: protect devlink param list by instance lock") Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Kim Phillips <kim.phillips@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * devlink: convert param list to xarrayJiri Pirko2023-02-133-39/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | Loose the linked list for params and use xarray instead. Note that this is required to be eventually possible to call devl_param_driverinit_value_get() without holding instance lock. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * devlink: use xa_for_each_start() helper in devlink_nl_cmd_port_get_dump_one()Jiri Pirko2023-02-131-8/+2
| | | | | | | | | | | | | | | | | | | | | | As xarray has an iterator helper that allows to start from specified index, use this directly and avoid repeated iteration from 0. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * devlink: fix the name of value arg of devl_param_driverinit_value_get()Jiri Pirko2023-02-132-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Probably due to copy-paste error, the name of the arg is "init_val" which is misleading, as the pointer is used to point to struct where to store the current value. Rename it to "val" and change the arg comment a bit on the way. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * devlink: make sure driver does not read updated driverinit param before reloadJiri Pirko2023-02-134-4/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driverinit param purpose is to serve the driver during init/reload time to provide a value, either default or set by user. Make sure that driver does not read value updated by user before the reload is performed. Hold the new value in a separate struct and switch it during reload. Note that this is required to be eventually possible to call devl_param_driverinit_value_get() without holding instance lock. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * devlink: don't use strcpy() to copy param valueJiri Pirko2023-02-131-12/+3
|/ | | | | | | | | | | | No need to treat string params any different comparing to other types. Rely on the struct assign to copy the whole struct, including the string. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* nfp: ethtool: supplement nfp link modes supportedYu Xiao2023-02-132-0/+15
| | | | | | | | | | | | | | | | Add support for the following modes to the nfp driver: NFP_MEDIA_10GBASE_LR NFP_MEDIA_25GBASE_LR NFP_MEDIA_25GBASE_ER These modes are supported by the hardware and, support for them was recently added to firmware. Signed-off-by: Yu Xiao <yu.xiao@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* devlink: stop using NL_SET_ERR_MSG_MODJacob Keller2023-02-132-70/+65
| | | | | | | | | | | | | | | NL_SET_ERR_MSG_MOD inserts the KBUILD_MODNAME and a ':' before the actual extended error message. The devlink feature hasn't been able to be compiled as a module since commit f4b6bcc7002f ("net: devlink: turn devlink into a built-in"). Stop using NL_SET_ERR_MSG_MOD, and just use the base NL_SET_ERR_MSG. This aligns the extended error messages better with the NL_SET_ERR_MSG_ATTR messages as well. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* rds: rds_rm_zerocopy_callback() correct order for list_add_tail()Pietro Borrello2023-02-131-1/+1
| | | | | | | | | | | rds_rm_zerocopy_callback() uses list_add_tail() with swapped arguments. This links the list head with the new entry, losing the references to the remaining part of the list. Fixes: 9426bbc6de99 ("rds: use list structure to track information for zerocopy completion notification") Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch '40GbE' of ↵Jakub Kicinski2023-02-1023-1591/+1424
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-02-09 (i40e) Jan removes i40e_status from the driver; replacing them with standard kernel error codes. Kees Cook replaces 0-length array with flexible array. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: net/i40e: Replace 0-length array with flexible array i40e: use ERR_PTR error print in i40e messages i40e: use int for i40e_status i40e: Remove string printing for i40e_status i40e: Remove unused i40e status codes ==================== Link: https://lore.kernel.org/r/20230209172536.3595838-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * net/i40e: Replace 0-length array with flexible arrayKees Cook2023-02-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Zero-length arrays are deprecated[1]. Replace struct i40e_lump_tracking's "list" 0-length array with a flexible array. Detected with GCC 13, using -fstrict-flex-arrays=3: In function 'i40e_put_lump', inlined from 'i40e_clear_interrupt_scheme' at drivers/net/ethernet/intel/i40e/i40e_main.c:5145:2: drivers/net/ethernet/intel/i40e/i40e_main.c:278:27: warning: array subscript <unknown> is outside array bounds of 'u16[0]' {aka 'short unsigned int[]'} [-Warray-bounds=] 278 | pile->list[i] = 0; | ~~~~~~~~~~^~~ drivers/net/ethernet/intel/i40e/i40e.h: In function 'i40e_clear_interrupt_scheme': drivers/net/ethernet/intel/i40e/i40e.h:179:13: note: while referencing 'list' 179 | u16 list[0]; | ^~~~ [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Cc: Tony Nguyen <anthony.l.nguyen@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * i40e: use ERR_PTR error print in i40e messagesJan Sokolowski2023-02-096-197/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In i40e_status removal patches, i40e_status conversion to strings was removed in order to easily refactor the code to use standard errornums. This however made it more difficult for read error logs. Use %pe formatter to print error messages in human-readable format. Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * i40e: use int for i40e_statusJan Sokolowski2023-02-0921-1203/+1221
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To prepare for removal of i40e_status, change the variables from i40e_status to int. This eases the transition when values are changed to return standard int error codes over enum i40e_status. As such changes often also change variable orders, a cleanup is also applied here to make variables conform to RCT and some lines are also reformatted where applicable. Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * i40e: Remove string printing for i40e_statusJan Sokolowski2023-02-098-282/+201
| | | | | | | | | | | | | | | | | | | | Remove the i40e_stat_str() function which prints the string representation of the i40e_status error code. With upcoming changes moving away from i40e_status, there will be no need for this function Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
| * i40e: Remove unused i40e status codesJan Sokolowski2023-02-092-105/+0
| | | | | | | | | | | | | | | | | | | | In an effort to remove i40e status codes and replace them with standard kernel errornums, unused values of i40e_status_code were removed. Signed-off-by: Jan Sokolowski <jan.sokolowski@intel.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
* | Merge branch 's390-net-updates-2023-02-06'Jakub Kicinski2023-02-1010-170/+150
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Alexandra Winter says: ==================== s390/net: updates 2023-02-06 Just maintenance patches, no functional changes. If you disagree with patch 4, we can leave it out. We prefer scnprintf, but no strong opinion. ==================== Link: https://lore.kernel.org/r/20230209110424.1707501-1-wintera@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | s390/qeth: Convert sprintf/snprintf to scnprintfThorsten Winkler2023-02-105-39/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This LWN article explains the rationale for this change https: //lwn.net/Articles/69419/ Ie. snprintf() returns what *would* be the resulting length, while scnprintf() returns the actual length. Reported-by: Jules Irenge <jbi.octave@gmail.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Thorsten Winkler <twinkler@linux.ibm.com> Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | s390/qeth: Convert sysfs sprintf to sysfs_emitThorsten Winkler2023-02-103-98/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following the advice of the Documentation/filesystems/sysfs.rst. All sysfs related show()-functions should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Reported-by: Jules Irenge <jbi.octave@gmail.com> Reported-by: Joe Perches <joe@perches.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Thorsten Winkler <twinkler@linux.ibm.com> Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | s390/qeth: Use constant for IP address buffersThorsten Winkler2023-02-102-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use INET6_ADDRSTRLEN constant with size of 48 which be used for char arrays storing ip addresses (for IPv4 and IPv6) Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Thorsten Winkler <twinkler@linux.ibm.com> Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | s390/ctcm: cleanup indentingAlexandra Winter2023-02-103-31/+32
|/ / | | | | | | | | | | | | | | | | Get rid of multiple smatch warnings, like: warn: inconsistent indenting Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | Merge branch 'net-renesas-rswitch-improve-tx-timestamp-accuracy'Jakub Kicinski2023-02-102-93/+248
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Yoshihiro Shimoda says: ==================== net: renesas: rswitch: Improve TX timestamp accuracy The patch [[123]/4] are minor refacoring for readability. The patch [4/4] is for improving TX timestamp accuracy. To improve the accuracy, it requires refactoring so that this is not a fixed patch. v2: https://lore.kernel.org/all/20230208235721.2336249-1-yoshihiro.shimoda.uh@renesas.com/ v1: https://lore.kernel.org/all/20230208073445.2317192-1-yoshihiro.shimoda.uh@renesas.com/ ==================== Link: https://lore.kernel.org/r/20230209081741.2536034-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | net: renesas: rswitch: Improve TX timestamp accuracyYoshihiro Shimoda2023-02-102-22/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the previous code, TX timestamp accuracy was bad because the irq handler got the timestamp from the timestamp register at that time. This hardware has "Timestamp capture" feature which can store each TX timestamp into the timestamp descriptors. To improve TX timestamp accuracy, implement timestamp descriptors' handling. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | net: renesas: rswitch: Remove gptp flag from rswitch_gwca_queueYoshihiro Shimoda2023-02-102-16/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the previous code, the gptp flag was completely related to the !dir_tx in struct rswitch_gwca_queue because rswitch_gwca_queue_alloc() was called below: < In rswitch_txdmac_alloc() > err = rswitch_gwca_queue_alloc(ndev, priv, rdev->tx_queue, true, false, TX_RING_SIZE); So, dir_tx = true, and gptp = false. < In rswitch_rxdmac_alloc() > err = rswitch_gwca_queue_alloc(ndev, priv, rdev->rx_queue, false, true, RX_RING_SIZE); So, dir_tx = false, and gptp = true. In the future, a new queue handling for timestamp will be implemented and this gptp flag is confusable. So, remove the gptp flag. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | net: renesas: rswitch: Move linkfix variables to rswitch_gwcaYoshihiro Shimoda2023-02-102-21/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | To improve readability, move linkfix related variables to struct rswitch_gwca. Also, rename function names "desc" with "linkfix". Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | net: renesas: rswitch: Rename rings in struct rswitch_gwca_queueYoshihiro Shimoda2023-02-102-34/+34
|/ / | | | | | | | | | | | | | | | | | | | | | | To add a new ring which is really related to timestamp (ts_ring) in the future, rename the following members to improve readability: ring --> tx_ring ts_ring --> rx_ring Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: libwx: fix an error code in wx_alloc_page_pool()Dan Carpenter2023-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | This function always returns success. We need to preserve the error code before setting rx_ring->page_pool = NULL. Fixes: 850b971110b2 ("net: libwx: Allocate Rx and Tx resources") Signed-off-by: Dan Carpenter <error27@gmail.com> Link: https://lore.kernel.org/r/Y+T4aoefc1XWvGYb@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: dsa: ocelot: add PTP dependency for NET_DSA_MSCC_OCELOT_EXTArnd Bergmann2023-02-102-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new user of MSCC_OCELOT_SWITCH_LIB was added, bringing back an old link failure that was fixed with e5f31552674e ("ethernet: fix PTP_1588_CLOCK dependencies"): x86_64-linux-ld: drivers/net/ethernet/mscc/ocelot_ptp.o: in function `ocelot_ptp_enable': ocelot_ptp.c:(.text+0x8ee): undefined reference to `ptp_find_pin' x86_64-linux-ld: drivers/net/ethernet/mscc/ocelot_ptp.o: in function `ocelot_get_ts_info': ocelot_ptp.c:(.text+0xd5d): undefined reference to `ptp_clock_index' x86_64-linux-ld: drivers/net/ethernet/mscc/ocelot_ptp.o: in function `ocelot_init_timestamp': ocelot_ptp.c:(.text+0x15ca): undefined reference to `ptp_clock_register' x86_64-linux-ld: drivers/net/ethernet/mscc/ocelot_ptp.o: in function `ocelot_deinit_timestamp': ocelot_ptp.c:(.text+0x16b7): undefined reference to `ptp_clock_unregister' Add the same PTP dependency here, as well as in the MSCC_OCELOT_SWITCH_LIB symbol itself to make it more obvious what is going on when the next driver selects it. Fixes: 3d7316ac81ac ("net: dsa: ocelot: add external ocelot switch control") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Colin Foster <colin.foster@in-advantage.com> Link: https://lore.kernel.org/r/20230209124435.1317781-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | Merge branch 'bridge-mcast-preparations-for-vxlan-mdb'Jakub Kicinski2023-02-102-21/+127
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ido Schimmel says: ==================== bridge: mcast: Preparations for VXLAN MDB This patchset contains small preparations for VXLAN MDB that were split from this RFC [1]. Tested using existing bridge MDB forwarding selftests. [1] https://lore.kernel.org/netdev/20230204170801.3897900-1-idosch@nvidia.com/ ==================== Link: https://lore.kernel.org/r/20230209071852.613102-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | selftests: forwarding: Add MDB dump test casesIdo Schimmel2023-02-101-0/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel maintains three markers for the MDB dump: 1. The last bridge device from which the MDB was dumped. 2. The last MDB entry from which the MDB was dumped. 3. The last port-group entry that was dumped. Add test cases for large scale MDB dump to make sure that all the configured entries are dumped and that the markers are used correctly. Specifically, create 2 bridges with 32 ports and add 256 MDB entries in which all the ports are member of. Test that each bridge reports 8192 (256 * 32) permanent entries. Do that with IPv4, IPv6 and L2 MDB entries. On my system, MDB dump of the above is contained in about 50 netlink messages. Example output: # ./bridge_mdb.sh [...] INFO: # Large scale dump tests TEST: IPv4 large scale dump tests [ OK ] TEST: IPv6 large scale dump tests [ OK ] TEST: L2 large scale dump tests [ OK ] [...] Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | bridge: mcast: Move validation to a policyIdo Schimmel2023-02-101-18/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Future patches are going to move parts of the bridge MDB code to the common rtnetlink code in preparation for VXLAN MDB support. To facilitate code sharing between both drivers, move the validation of the top level attributes in RTM_{NEW,DEL}MDB messages to a policy that will eventually be moved to the rtnetlink code. Use 'NLA_NESTED' for 'MDBA_SET_ENTRY_ATTRS' instead of NLA_POLICY_NESTED() as this attribute is going to be validated using different policies in the underlying drivers. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | bridge: mcast: Remove pointless sequence generation counter assignmentIdo Schimmel2023-02-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of the sequence generation counter in the netlink callback is to identify if a multipart dump is consistent or not by calling nl_dump_check_consistent() whenever a message is generated. The function is not invoked by the MDB code, rendering the sequence generation counter assignment pointless. Remove it. Note that even if the function was invoked, we still could not accurately determine if the dump is consistent or not, as there is no sequence generation counter for MDB entries, unlike nexthop objects, for example. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | bridge: mcast: Use correct define in MDB dumpIdo Schimmel2023-02-101-1/+1
|/ / | | | | | | | | | | | | | | | | | | 'MDB_PG_FLAGS_PERMANENT' and 'MDB_PERMANENT' happen to have the same value, but the latter is uAPI and cannot change, so use it when dumping an MDB entry. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | Merge tag 'for-net-next-2023-02-09' of ↵Jakub Kicinski2023-02-1010-41/+188
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Luiz Augusto von Dentz says: ==================== pull-request: bluetooth-next - Add new PID/VID 0489:e0f2 for MT7921 - Add VID:PID 13d3:3529 for Realtek RTL8821CE - Add CIS feature bits to controller information - Set Per Platform Antenna Gain(PPAG) for Intel controllers * tag 'for-net-next-2023-02-09' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next: Bluetooth: btintel: Set Per Platform Antenna Gain(PPAG) Bluetooth: Make sure LE create conn cancel is sent when timeout Bluetooth: Free potentially unfreed SCO connection Bluetooth: hci_qca: get wakeup status from serdev device handle Bluetooth: L2CAP: Fix potential user-after-free Bluetooth: MGMT: add CIS feature bits to controller information Bluetooth: hci_conn: Refactor hci_bind_bis() since it always succeeds Bluetooth: HCI: Replace zero-length arrays with flexible-array members Bluetooth: qca: Fix sparse warnings Bluetooth: btusb: Add VID:PID 13d3:3529 for Realtek RTL8821CE Bluetooth: btusb: Add new PID/VID 0489:e0f2 for MT7921 Bluetooth: Fix issue with Actions Semi ATS2851 based devices ==================== Link: https://lore.kernel.org/r/20230209234922.3756173-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | Bluetooth: btintel: Set Per Platform Antenna Gain(PPAG)Seema Sreemantha2023-02-092-0/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Antenna gain is defined as the antenna’s ability to increase the Tx power in a given direction. Intel is certifying its products with fixed reference antenna peak gain values (3/5dBi). The feature takes into account the actual antenna gain, and increases output power values, which results in a performance improvement. After firmware download is completed, driver reads from ACPI table and configures PPAG as required. ACPI table entry for PPAG is defined as below. Name (PPAG, Package (0x02) { 0x00000001, Package (0x02) { 0x00000012, /* Bluetooth Domain */ 0x00000001 /* 1 - Enable PPAG, 0 - Disable PPAG */ } }) btmon log: < HCI Command: Intel Configure Per Platform Antenna Gain (0x3f|0x0219) plen 12 Mcc: 0x00000000 Selector: Enable Delta: 0x00000000 > HCI Event: Command Complete (0x0e) plen 4 Intel Configure Per Platform Antenna Gain (0x3f|0x0219) ncmd 1 Status: Success (0x00) Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Seema Sreemantha <seema.sreemantha@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: Make sure LE create conn cancel is sent when timeoutArchie Pusaka2023-02-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When sending LE create conn command, we set a timer with a duration of HCI_LE_CONN_TIMEOUT before timing out and calling create_le_conn_complete. Additionally, when receiving the command complete, we also set a timer with the same duration to call le_conn_timeout. Usually the latter will be triggered first, which then sends a LE create conn cancel command. However, due to the nature of racing, it is possible for the former to be called first, thereby calling the chain hci_conn_failed -> hci_conn_del -> cancel_delayed_work, thereby preventing LE create conn cancel to be sent. In this situation, the controller will be stuck in trying the LE connection. This patch flushes le_conn_timeout on create_le_conn_complete to make sure we always send LE create connection cancel, if necessary. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Ying Hsu <yinghsu@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: Free potentially unfreed SCO connectionArchie Pusaka2023-02-091-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible to initiate a SCO connection while deleting the corresponding ACL connection, e.g. in below scenario: (1) < hci setup sync connect command (2) > hci disconn complete event (for the acl connection) (3) > hci command complete event (for(1), failure) When it happens, hci_cs_setup_sync_conn won't be able to obtain the reference to the SCO connection, so it will be stuck and potentially hinder subsequent connections to the same device. This patch prevents that by also deleting the SCO connection if it is still not established when the corresponding ACL connection is deleted. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Ying Hsu <yinghsu@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: hci_qca: get wakeup status from serdev device handleZhengping Jiang2023-02-091-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bluetooth controller attached via the UART is handled by the serdev driver. Get the wakeup status from the device handle through serdev, instead of the parent path. Fixes: c1a74160eaf1 ("Bluetooth: hci_qca: Add device_may_wakeup support") Signed-off-by: Zhengping Jiang <jiangzp@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: L2CAP: Fix potential user-after-freeLuiz Augusto von Dentz2023-02-092-24/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes all instances of which requires to allocate a buffer calling alloc_skb which may release the chan lock and reacquire later which makes it possible that the chan is disconnected in the meantime. Fixes: a6a5568c03c4 ("Bluetooth: Lock the L2CAP channel when sending") Reported-by: Alexander Coffin <alex.coffin@matician.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: MGMT: add CIS feature bits to controller informationPauli Virtanen2023-02-092-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Userspace needs to know whether the adapter has feature support for Connected Isochronous Stream - Central/Peripheral, so it can set up LE Audio features accordingly. Expose these feature bits as settings in MGMT controller info. Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: hci_conn: Refactor hci_bind_bis() since it always succeedsKees Cook2023-02-091-9/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The compiler thinks "conn" might be NULL after a call to hci_bind_bis(), which cannot happen. Avoid any confusion by just making it not return a value since it cannot fail. Fixes the warnings seen with GCC 13: In function 'arch_atomic_dec_and_test', inlined from 'atomic_dec_and_test' at ../include/linux/atomic/atomic-instrumented.h:576:9, inlined from 'hci_conn_drop' at ../include/net/bluetooth/hci_core.h:1391:6, inlined from 'hci_connect_bis' at ../net/bluetooth/hci_conn.c:2124:3: ../arch/x86/include/asm/rmwcc.h:37:9: warning: array subscript 0 is outside array bounds of 'atomic_t[0]' [-Warray-bounds=] 37 | asm volatile (fullop CC_SET(cc) \ | ^~~ ... In function 'hci_connect_bis': cc1: note: source object is likely at address zero Fixes: eca0ae4aea66 ("Bluetooth: Add initial implementation of BIS connections") Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: linux-bluetooth@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: HCI: Replace zero-length arrays with flexible-array membersGustavo A. R. Silva2023-02-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Zero-length arrays are deprecated[1] and we are moving towards adopting C99 flexible-array members instead. So, replace zero-length arrays in a couple of structures with flex-array members. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [2]. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2] Link: https://github.com/KSPP/linux/issues/78 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: qca: Fix sparse warningsLuiz Augusto von Dentz2023-02-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the following warnings: drivers/bluetooth/hci_qca.c:1014:26: warning: cast to restricted __le16 drivers/bluetooth/hci_qca.c:1028:37: warning: cast to restricted __le32 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: btusb: Add VID:PID 13d3:3529 for Realtek RTL8821CEMoises Cardona2023-02-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds VID:PID 13d3:3529 to the btusb.c file. This VID:PID is found in the Realtek RTL8821CE module (M.2 module AW-CB304NF on an ASUS E210MA laptop) Output of /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3529 Rev= 1.10 S: Manufacturer=Realtek S: Product=Bluetooth Radio C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Moises Cardona <moisesmcardona@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: btusb: Add new PID/VID 0489:e0f2 for MT7921Mario Limonciello2023-02-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bluetooth device is found in a combo WLAN/BT card for a MediaTek 7921e. The device information: T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e0f2 Rev= 1.00 S: Manufacturer=MediaTek Inc. S: Product=Wireless_Device S: SerialNumber=000000000 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us Cc: Sean Wang <sean.wang@mediatek.com> Cc: Anson Tsao <anson.tsao@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
| * | Bluetooth: Fix issue with Actions Semi ATS2851 based devicesMarcel Holtmann2023-02-091-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Their devices claim to support the erroneous data reporting, but don't actually support the required commands. So blacklist them and add a quirk. < HCI Command: Read Default Erroneous Data Reporting (0x03|0x005a) plen 0 > HCI Event: Command Status (0x0f) plen 4 Read Default Erroneous Data Reporting (0x03|0x005a) ncmd 1 Status: Unknown HCI Command (0x01) T: Bus=02 Lev=02 Prnt=08 Port=02 Cnt=01 Dev#= 10 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=10d7 ProdID=b012 Rev=88.91 S: Manufacturer=Actions S: Product=general adapter S: SerialNumber=ACTIONS1234 C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=01(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=01(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=01(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=01(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=01(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=01(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
* | | Daniel Borkmann says:Jakub Kicinski2023-02-10152-962/+4884
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ==================== pull-request: bpf-next 2023-02-11 We've added 96 non-merge commits during the last 14 day(s) which contain a total of 152 files changed, 4884 insertions(+), 962 deletions(-). There is a minor conflict in drivers/net/ethernet/intel/ice/ice_main.c between commit 5b246e533d01 ("ice: split probe into smaller functions") from the net-next tree and commit 66c0e13ad236 ("drivers: net: turn on XDP features") from the bpf-next tree. Remove the hunk given ice_cfg_netdev() is otherwise there a 2nd time, and add XDP features to the existing ice_cfg_netdev() one: [...] ice_set_netdev_features(netdev); netdev->xdp_features = NETDEV_XDP_ACT_BASIC | NETDEV_XDP_ACT_REDIRECT | NETDEV_XDP_ACT_XSK_ZEROCOPY; ice_set_ops(netdev); [...] Stephen's merge conflict mail: https://lore.kernel.org/bpf/20230207101951.21a114fa@canb.auug.org.au/ The main changes are: 1) Add support for BPF trampoline on s390x which finally allows to remove many test cases from the BPF CI's DENYLIST.s390x, from Ilya Leoshkevich. 2) Add multi-buffer XDP support to ice driver, from Maciej Fijalkowski. 3) Add capability to export the XDP features supported by the NIC. Along with that, add a XDP compliance test tool, from Lorenzo Bianconi & Marek Majtyka. 4) Add __bpf_kfunc tag for marking kernel functions as kfuncs, from David Vernet. 5) Add a deep dive documentation about the verifier's register liveness tracking algorithm, from Eduard Zingerman. 6) Fix and follow-up cleanups for resolve_btfids to be compiled as a host program to avoid cross compile issues, from Jiri Olsa & Ian Rogers. 7) Batch of fixes to the BPF selftest for xdp_hw_metadata which resulted when testing on different NICs, from Jesper Dangaard Brouer. 8) Fix libbpf to better detect kernel version code on Debian, from Hao Xiang. 9) Extend libbpf to add an option for when the perf buffer should wake up, from Jon Doron. 10) Follow-up fix on xdp_metadata selftest to just consume on TX completion, from Stanislav Fomichev. 11) Extend the kfuncs.rst document with description on kfunc lifecycle & stability expectations, from David Vernet. 12) Fix bpftool prog profile to skip attaching to offline CPUs, from Tonghao Zhang. ==================== Link: https://lore.kernel.org/r/20230211002037.8489-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | | libbpf: Fix alen calculation in libbpf_nla_dump_errormsg()Ilya Leoshkevich2023-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code assumes that everything that comes after nlmsgerr are nlattrs. When calculating their size, it does not account for the initial nlmsghdr. This may lead to accessing uninitialized memory. Fixes: bbf48c18ee0c ("libbpf: add error reporting in XDP") Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20230210001210.395194-8-iii@linux.ibm.com
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-03 07:38:35 +0000