summaryrefslogtreecommitdiffstats
path: root/drivers/net
Commit message (Collapse)AuthorAgeFilesLines
* net: ipa: define remaining IPA status field valuesAlex Elder2023-01-271-9/+22
| | | | | | | | | | | Define the remaining values for opcode and exception fields in the IPA packet status structure. Most of these values are powers-of-2, suggesting they are meant to be used as bitmasks, but that is not the case. Add comments to be clear about this, and express the values in decimal format. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ipa: rename the NAT enumerated typeAlex Elder2023-01-272-6/+8
| | | | | | | | | Rename the ipa_nat_en enumerated type to be ipa_nat_type, and rename its symbols accordingly. Add a comment indicating those values are also used in the IPA status nat_type field. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ipa: define all IPA status mask bitsAlex Elder2023-01-271-3/+22
| | | | | | | | | | | | | There is a 16 bit status mask defined in the IPA packet status structure, of which only one (TAG_VALID) is currently used. Define all other IPA status mask values in an enumerated type whose numeric values are bit mask values (in CPU byte order) in the status mask. Use the TAG_VALID value from that type rather than defining a separate field mask. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ipa: stop using sizeof(status)Alex Elder2023-01-271-6/+9
| | | | | | | | | | The IPA packet status structure changes in IPA v5.0 in ways that are difficult to represent cleanly. As a small step toward redefining it as a parsed block of data, use a constant to define its size, rather than the size of the IPA status structure type. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ipa: refactor status buffer parsingAlex Elder2023-01-271-8/+6
| | | | | | | | | | | | | The packet length encoded in an IPA packet status buffer is computed more than once in ipa_endpoint_status_parse(). It is also checked again in ipa_endpoint_status_skip(), which that function calls. Compute the length once, and use that computed value later rather than recomputing it. Check for it being zero in the parse function rather than in ipa_endpoint_status_skip(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: ocelot: build felix.c into a dedicated kernel moduleVladimir Oltean2023-01-263-7/+21
| | | | | | | | | | | | | | | | The build system currently complains: scripts/Makefile.build:252: drivers/net/dsa/ocelot/Makefile: felix.o is added to multiple modules: mscc_felix mscc_seville Since felix.c holds the DSA glue layer, create a mscc_felix_dsa_lib.ko. This is similar to how mscc_ocelot_switch_lib.ko holds a library for configuring the hardware. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Colin Foster <colin.foster@in-advantage.com> Link: https://lore.kernel.org/r/20230125145716.271355-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* Merge branch '40GbE' of ↵Jakub Kicinski2023-01-2610-62/+63
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== virtchnl: update and refactor Jesse Brandeburg says: The virtchnl.h file is used by i40e/ice physical function (PF) drivers and irdma when talking to the iavf driver. This series cleans up the header file by removing unused elements, adding/cleaning some comments, fixing the data structures so they are explicitly defined, including padding, and finally does a long overdue rename of the IWARP members in the structures to RDMA, since the ice driver and it's associated Intel Ethernet E800 series adapters support both RDMA and IWARP. The whole series should result in no functional change, but hopefully clearer code. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: virtchnl: i40e/iavf: rename iwarp to rdma virtchnl: do structure hardening virtchnl: update header and increase header clarity virtchnl: remove unused structure declaration ==================== Link: https://lore.kernel.org/r/20230125212441.4030014-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * virtchnl: i40e/iavf: rename iwarp to rdmaJesse Brandeburg2023-01-2510-62/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the latest Intel hardware does both IWARP and ROCE, rename the term IWARP in the virtchnl header to be RDMA. Do this for both upper and lower case instances. Many of the non-virtchnl.h changes were done with regular expression replacements using perl like: perl -p -i -e 's/_IWARP/_RDMA/' <files> perl -p -i -e 's/_iwarp/_rdma/' <files> and I had to pick up a few instances manually. The virtchnl.h header has some comments and clarity added around when to use certain defines. note: had to fix a checkpatch warning for a long line by wrapping one of the lines I changed. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Jakub Andrysiak <jakub.andrysiak@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
* | cxgb4: fill IPsec state validation failure reasonLeon Romanovsky2023-01-262-16/+15
| | | | | | | | | | | | | | Rely on extack to return failure reason. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | bonding: fill IPsec state validation failure reasonLeon Romanovsky2023-01-261-1/+1
| | | | | | | | | | | | | | Rely on extack to return failure reason. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | ixgbe: fill IPsec state validation failure reasonLeon Romanovsky2023-01-261-11/+10
| | | | | | | | | | | | | | Rely on extack to return failure reason. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | ixgbevf: fill IPsec state validation failure reasonLeon Romanovsky2023-01-261-9/+8
| | | | | | | | | | | | | | Rely on extack to return failure reason. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | nfp: fill IPsec state validation failure reasonLeon Romanovsky2023-01-261-19/+19
| | | | | | | | | | | | | | | | Rely on extack to return failure reason. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | netdevsim: Fill IPsec state validation failure reasonLeon Romanovsky2023-01-261-6/+5
| | | | | | | | | | | | | | Rely on extack to return failure reason. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net/mlx5e: Fill IPsec state validation failure reasonLeon Romanovsky2023-01-261-43/+32
| | | | | | | | | | | | | | Rely on extack to return failure reason. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | xfrm: extend add state callback to set failure reasonLeon Romanovsky2023-01-268-13/+25
| | | | | | | | | | | | | | | | | | | | | | Almost all validation logic is in the drivers, but they are missing reliable way to convey failure reason to userspace applications. Let's use extack to return this information to users. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net/mlx5e: Fill IPsec policy validation failure reasonLeon Romanovsky2023-01-261-10/+12
| | | | | | | | | | | | | | Rely on extack to return failure reason. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | xfrm: extend add policy callback to set failure reasonLeon Romanovsky2023-01-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | Almost all validation logic is in the drivers, but they are missing reliable way to convey failure reason to userspace applications. Let's use extack to return this information to users. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | net: ethtool: provide shims for stats aggregation helpers when ↵Vladimir Oltean2023-01-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_ETHTOOL_NETLINK=n ethtool_aggregate_*_stats() are implemented in net/ethtool/stats.c, a file which is compiled out when CONFIG_ETHTOOL_NETLINK=n. In order to avoid adding Kbuild dependencies from drivers (which call these helpers) on CONFIG_ETHTOOL_NETLINK, let's add some shim definitions which simply make the helpers dead code. This means the function prototypes should have been located in include/linux/ethtool_netlink.h rather than include/linux/ethtool.h. Fixes: 449c5459641a ("net: ethtool: add helpers for aggregate statistics") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20230125110214.4127759-1-vladimir.oltean@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: microchip: sparx5: Add support for IS0 VCAP CVLAN TC keysSteen Hegelund2023-01-261-0/+51
| | | | | | | | | | | | | | | | This adds support for parsing and matching on the CVLAN tags in the Sparx5 IS0 VCAP. Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: microchip: sparx5: Add support for IS0 VCAP ethernet protocol typesSteen Hegelund2023-01-263-30/+43
| | | | | | | | | | | | | | | | | | This allows the IS0 VCAP to have its own list of supported ethernet protocol types matching what is supported by the VCAPs port lookup classification. Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: microchip: sparx5: Add automatic selection of VCAP rule actionsetSteen Hegelund2023-01-263-10/+109
| | | | | | | | | | | | | | | | | | With more than one possible actionset in a VCAP instance, the VCAP API will now use the actions in a VCAP rule to select the actionset that fits these actions the best possible way. Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: microchip: sparx5: Add TC filter chaining support for IS0 and IS2 VCAPsSteen Hegelund2023-01-263-2/+136
| | | | | | | | | | | | | | | | | | | | | | | | This allows rules to be chained between VCAP instances, e.g. from IS0 Lookup 0 to IS0 Lookup 1, or from one of the IS0 Lookups to one of the IS2 Lookups. Chaining from an IS2 Lookup to another IS2 Lookup is not supported in the hardware. Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: microchip: sparx5: Add TC support for IS0 VCAPSteen Hegelund2023-01-261-9/+45
| | | | | | | | | | | | | | This enables the TC command to use the Sparx5 IS0 VCAP Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: microchip: sparx5: Add actionset type id information to ruleSteen Hegelund2023-01-261-0/+34
| | | | | | | | | | | | | | | | This adds the actionset type id to the rule information. This is needed as we now have more than one actionset in a VCAP instance (IS0). Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: microchip: sparx5: Add IS0 VCAP keyset configuration for Sparx5Steen Hegelund2023-01-264-54/+564
| | | | | | | | | | | | | | | | This adds the IS0 VCAP port keyset configuration for Sparx5 and also updates the debugFS support to show the keyset configuration. Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* | net: microchip: sparx5: Add IS0 VCAP model and updated KUNIT VCAP modelSteen Hegelund2023-01-264-1821/+1145
|/ | | | | | | | This provides the IS0 (Ingress Stage 0) or CLM VCAP model for Sparx5. This VCAP provides classification actions for Sparx5. Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* virtio-net: Reduce debug name field size to 16 bytesParav Pandit2023-01-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | virtio queue index can be maximum of 65535. 16 bytes are enough to store the vq name with the existing string prefix. With this change, send queue struct saves 24 bytes and receive queue saves whole cache line worth 64 bytes per structure due to saving in alignment bytes. Pahole results before: pahole -s drivers/net/virtio_net.o | \ grep -e "send_queue" -e "receive_queue" send_queue 1112 0 receive_queue 1280 1 Pahole results after: pahole -s drivers/net/virtio_net.o | \ grep -e "send_queue" -e "receive_queue" send_queue 1088 0 receive_queue 1216 1 Signed-off-by: Parav Pandit <parav@nvidia.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: mscc: ocelot: fix incorrect verify_enabled reporting in ethtool get_mm()Vladimir Oltean2023-01-241-0/+1
| | | | | | | | | | | | | We don't read the verify_enabled variable from hardware in the MAC Merge layer state GET operation, instead we always leave it set to "false". The user may think something is wrong if they set verify_enabled to true, then read it back and see it's still false, even though the configuration took place. Fixes: 6505b6805655 ("net: mscc: ocelot: add MAC Merge layer support for VSC9959") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20230123184538.3420098-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* nfp: flower: change get/set_eeprom logic and enable for flower repsJames Hershaw2023-01-241-4/+7
| | | | | | | | | | | | | | | | | | | | | | The changes in this patch are as follows: - Alter the logic of get/set_eeprom functions to use the helper function nfp_app_from_netdev() which handles differentiating between an nfp_net and a nfp_repr. This allows us to get an agnostic backpointer to the pdev. - Enable the various eeprom commands by adding the 'get_eeprom_len', 'get_eeprom', 'set_eeprom' callbacks to the nfp_port_ethtool_ops struct. This allows the eeprom commands to work on representor interfaces, similar to a previous patch which added it to the vnics. Currently these are being used to configure persistent MAC addresses for the physical ports on the nfp. Signed-off-by: James Hershaw <james.hershaw@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230123134135.293278-1-simon.horman@corigine.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: ethernet: ti: am65-cpsw/cpts: Fix CPTS release actionSiddharth Vadapalli2023-01-243-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | The am65_cpts_release() function is registered as a devm_action in the am65_cpts_create() function in am65-cpts driver. When the am65-cpsw driver invokes am65_cpts_create(), am65_cpts_release() is added in the set of devm actions associated with the am65-cpsw driver's device. In the event of probe failure or probe deferral, the platform_drv_probe() function invokes dev_pm_domain_detach() which powers off the CPSW and the CPSW's CPTS hardware, both of which share the same power domain. Since the am65_cpts_disable() function invoked by the am65_cpts_release() function attempts to reset the CPTS hardware by writing to its registers, the CPTS hardware is assumed to be powered on at this point. However, the hardware is powered off before the devm actions are executed. Fix this by getting rid of the devm action for am65_cpts_release() and invoking it directly on the cleanup and exit paths. Fixes: f6bd59526ca5 ("net: ethernet: ti: introduce am654 common platform time sync driver") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: ethernet: ti: am65-cpsw: Delete unreachable error handling codeSiddharth Vadapalli2023-01-241-5/+0
| | | | | | | | | | | | | | | | The am65_cpts_create() function returns -EOPNOTSUPP only when the config "CONFIG_TI_K3_AM65_CPTS" is disabled. Also, in the am65_cpsw_init_cpts() function, am65_cpts_create() can only be invoked if the config "CONFIG_TI_K3_AM65_CPTS" is enabled. Thus, the error handling code for the case in which the return value of am65_cpts_create() is -EOPNOTSUPP, is unreachable. Hence delete it. Reported-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
* net: phy: microchip: run phy initialization during each link updateRakesh Sankaranarayanan2023-01-231-14/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | PHY initialization is supposed to run on every mode changes. "lan87xx_config_aneg()" verifies every mode change using "phy_modify_changed()" function. Earlier code had phy_modify_changed() followed by genphy_soft_reset. But soft_reset resets all the pre-configured register values to default state, and lost all the initialization done. With this reason gen_phy_reset was removed. But it need to go through init sequence each time the mode changed. Update lan87xx_config_aneg() to invoke phy_init once successful mode update is detected. PHY init sequence added in lan87xx_phy_init() have slave init commands executed every time. Update the init sequence to run slave init only if phydev is in slave mode. Test setup contains LAN9370 EVB connected to SAMA5D3 (Running DSA), and issue can be reproduced by connecting link to any of the available ports after SAMA5D3 boot-up. With this issue, port will fail to update link state. But once the SAMA5D3 is reset with LAN9370 link in connected state itself, on boot-up link state will be reported as UP. But Again after some time, if link is moved to DOWN state, it will not get reported. Signed-off-by: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230120104733.724701-1-rakesh.sankaranarayanan@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: microchip: add support for credit based shaperArun Ramadoss2023-01-238-25/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | KSZ9477, KSZ9567, KSZ9563, KSZ8563 and LAN937x supports Credit based shaper. To differentiate the chip supporting cbs, tc_cbs_supported flag is introduced in ksz_chip_data. And KSZ series has 16bit Credit increment registers whereas LAN937x has 24bit register. The value to be programmed in the credit increment is determined using the successive multiplication method to convert decimal fraction to hexadecimal fraction. For example: if idleslope is 10000 and sendslope is -90000, then bandwidth is 10000 - (-90000) = 100000. The 10% bandwidth of 100Mbps means 10/100 = 0.1(decimal). This value has to be converted to hexa. 1) 0.1 * 16 = 1.6 --> fraction 0.6 Carry = 1 (MSB) 2) 0.6 * 16 = 9.6 --> fraction 0.6 Carry = 9 3) 0.6 * 16 = 9.6 --> fraction 0.6 Carry = 9 4) 0.6 * 16 = 9.6 --> fraction 0.6 Carry = 9 5) 0.6 * 16 = 9.6 --> fraction 0.6 Carry = 9 6) 0.6 * 16 = 9.6 --> fraction 0.6 Carry = 9 (LSB) Now 0.1(decimal) becomes 0.199999(Hex). If it is LAN937x, 24 bit value will be programmed to Credit Inc register, 0x199999. For others 16 bit value will be prgrammed, 0x1999. Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: dsa: microchip: enable port queues for tc mqprioArun Ramadoss2023-01-236-1/+47
| | | | | | | | | | | | LAN937x family of switches has 8 queues per port where the KSZ switches has 4 queues per port. By default, only one queue per port is enabled. The queues are configurable in 2, 4 or 8. This patch add 8 number of queues for LAN937x and 4 for other switches. In the tag_ksz.c file, prioirty of the packet is queried using the skb buffer and the corresponding value is updated in the tag. Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: microchip: sparx5: Fix uninitialized variable in vcap_path_exist()Dan Carpenter2023-01-231-1/+2
| | | | | | | | | | | The "eport" variable needs to be initialized to NULL for this code to work. Fixes: 814e7693207f ("net: microchip: vcap api: Add a storage state to a VCAP rule") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Link: https://lore.kernel.org/r/Y8qbYAb+YSXo1DgR@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* net: mdio: warn once if addr parameter is invalid in mdiobus_get_phy()Heiner Kallweit2023-01-231-1/+2
| | | | | | | | | | | If mdiobus_get_phy() is called with an invalid addr parameter, then the caller has a bug. Print a call trace to help identifying the caller. Suggested-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/daec3f08-6192-ba79-f74b-5beb436cab6c@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* Merge tag 'wireless-next-2023-01-23' of ↵Jakub Kicinski2023-01-2387-1209/+4808
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.3 First set of patches for v6.3. The most important change here is that the old Wireless Extension user space interface is not supported on Wi-Fi 7 devices at all. We also added a warning if anyone with modern drivers (ie. cfg80211 and mac80211 drivers) tries to use Wireless Extensions, everyone should switch to using nl80211 interface instead. Static WEP support is removed, there wasn't any driver using that anyway so there's no user impact. Otherwise it's smaller features and fixes as usual. Note: As mt76 had tricky conflicts due to the fixes in wireless tree, we decided to merge wireless into wireless-next to solve them easily. There should not be any merge problems anymore. Major changes: cfg80211 - remove never used static WEP support - warn if Wireless Extention interface is used with cfg80211/mac80211 drivers - stop supporting Wireless Extensions with Wi-Fi 7 devices - support minimal Wi-Fi 7 Extremely High Throughput (EHT) rate reporting rfkill - add GPIO DT support bitfield - add FIELD_PREP_CONST() mt76 - per-PHY LED support rtw89 - support new Bluetooth co-existance version rtl8xxxu - support RTL8188EU * tag 'wireless-next-2023-01-23' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (123 commits) wifi: wireless: deny wireless extensions on MLO-capable devices wifi: wireless: warn on most wireless extension usage wifi: mac80211: drop extra 'e' from ieeee80211... name wifi: cfg80211: Deduplicate certificate loading bitfield: add FIELD_PREP_CONST() wifi: mac80211: add kernel-doc for EHT structure mac80211: support minimal EHT rate reporting on RX wifi: mac80211: Add HE MU-MIMO related flags in ieee80211_bss_conf wifi: mac80211: Add VHT MU-MIMO related flags in ieee80211_bss_conf wifi: cfg80211: Use MLD address to indicate MLD STA disconnection wifi: cfg80211: Support 32 bytes KCK key in GTK rekey offload wifi: cfg80211: Fix extended KCK key length check in nl80211_set_rekey_data() wifi: cfg80211: remove support for static WEP wifi: rtl8xxxu: Dump the efuse only for untested devices wifi: rtl8xxxu: Print the ROM version too wifi: rtw88: Use non-atomic sta iterator in rtw_ra_mask_info_update() wifi: rtw88: Use rtw_iterate_vifs() for rtw_vif_watch_dog_iter() wifi: rtw88: Move register access from rtw_bf_assoc() outside the RCU wifi: rtl8xxxu: Use a longer retry limit of 48 wifi: rtl8xxxu: Report the RSSI to the firmware ... ==================== Link: https://lore.kernel.org/r/20230123103338.330CBC433EF@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * wifi: mac80211: drop extra 'e' from ieeee80211... nameJohannes Berg2023-01-191-2/+2
| | | | | | | | | | | | | | Somehow an extra 'e' slipped in there without anyone noticing, drop that from ieeee80211_obss_color_collision_notify(). Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * Merge wireless into wireless-nextKalle Valo2023-01-17136-688/+1259
| |\ | | | | | | | | | | | | | | | | | | | | | | | | Due to the two cherry picked commits from wireless to wireless-next we have several conflicts in mt76. To avoid any bugs with conflicts merge wireless into wireless-next. 96f134dc1964 wifi: mt76: handle possible mt76_rx_token_consume failures fe13dad8992b wifi: mt76: dma: do not increment queue head if mt76_dma_add_buf fails
| * | wifi: rtl8xxxu: Dump the efuse only for untested devicesBitterblue Smith2023-01-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears this was the intention all along, but commit 3307d84024d2 ("rtl8xxxu: Add initial code to parse rtl8192eu efuse") initialised rtl8xxxu_debug with RTL8XXXU_DEBUG_EFUSE for no apparent reason, which made it dump the efuse for all devices, even the tested ones. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/d53fcf97-d6d2-3c75-14d5-97b58a5f3a6c@gmail.com
| * | wifi: rtl8xxxu: Print the ROM version tooBitterblue Smith2023-01-161-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make rtl8xxxu_print_chipinfo() print the ROM version. This is relevant at least for the RTL8723AU and possibly relevant for the RTL8710BU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/add46396-95af-1164-2033-7d4eb4d0b554@gmail.com
| * | wifi: rtw88: Use non-atomic sta iterator in rtw_ra_mask_info_update()Martin Blumenstingl2023-01-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB and (upcoming) SDIO support may sleep in the read/write handlers. Use non-atomic rtw_iterate_stas() in rtw_ra_mask_info_update() because the iterator function rtw_ra_mask_info_update_iter() needs to read and write registers from within rtw_update_sta_info(). Using the non-atomic iterator ensures that we can sleep during USB and SDIO register reads and writes. This fixes "scheduling while atomic" or "Voluntary context switch within RCU read-side critical section!" warnings as seen by SDIO card users (but it also affects USB cards). Fixes: 78d5bf925f30 ("wifi: rtw88: iterate over vif/sta list non-atomically") Suggested-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230108211324.442823-4-martin.blumenstingl@googlemail.com
| * | wifi: rtw88: Use rtw_iterate_vifs() for rtw_vif_watch_dog_iter()Martin Blumenstingl2023-01-161-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB and (upcoming) SDIO support may sleep in the read/write handlers. Make rtw_watch_dog_work() use rtw_iterate_vifs() to prevent "scheduling while atomic" or "Voluntary context switch within RCU read-side critical section!" warnings when accessing the registers using an SDIO card (which is where this issue has been spotted in the real world but it also affects USB cards). Fixes: 78d5bf925f30 ("wifi: rtw88: iterate over vif/sta list non-atomically") Suggested-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230108211324.442823-3-martin.blumenstingl@googlemail.com
| * | wifi: rtw88: Move register access from rtw_bf_assoc() outside the RCUMartin Blumenstingl2023-01-161-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB and (upcoming) SDIO support may sleep in the read/write handlers. Shrink the RCU critical section so it only cover the call to ieee80211_find_sta() and finding the ic_vht_cap/vht_cap based on the found station. This moves the chip's BFEE configuration outside the rcu_read_lock section and thus prevent "scheduling while atomic" or "Voluntary context switch within RCU read-side critical section!" warnings when accessing the registers using an SDIO card (which is where this issue has been spotted in the real world - but it also affects USB cards). Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230108211324.442823-2-martin.blumenstingl@googlemail.com
| * | wifi: rtl8xxxu: Use a longer retry limit of 48Bitterblue Smith2023-01-161-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Realtek rate control algorithm goes back and forth a lot between the highest and the lowest rate it's allowed to use. This is due to a lot of frames being dropped because the retry limits set by IEEE80211_CONF_CHANGE_RETRY_LIMITS are too low. (Experimentally, they are 4 for long frames and 7 for short frames.) The vendor drivers hardcode the value 48 for both retry limits (for station mode), which makes dropped frames very rare and thus the rate control is more stable. Because most Realtek chips handle the rate control in the firmware, which can't be modified, ignore the limits set by IEEE80211_CONF_CHANGE_RETRY_LIMITS and use the value 48 (set during chip initialisation), same as the vendor drivers. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/477d745b-6bac-111d-403c-487fc19aa30d@gmail.com
| * | wifi: rtl8xxxu: Report the RSSI to the firmwareBitterblue Smith2023-01-168-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Or in the case of RTL8188EU, report the RSSI to the rate control code. The rate control code for RTL8188EU is less likely to switch to a lower rate when the RSSI is high. The firmware-based rate control in the other chips probably works the same way. This affects all the chips, but it was only tested with RTL8188EU, RTL8188FU, and RTL8192EU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/2aab4f3f-e914-4fe1-f29a-deac91774d05@gmail.com
| * | wifi: rt2x00: Remove useless else ifJiapeng Chong2023-01-161-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The assignment of the else and else if branches is the same, so the else if here is redundant, so we remove it. ./drivers/net/wireless/ralink/rt2x00/rt2800lib.c:8927:9-11: WARNING: possible condition with no effect (if == else). Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3631 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Acked-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230106022731.111243-1-jiapeng.chong@linux.alibaba.com
| * | wifi: mt7601u: fix an integer underflowJisoo Jang2023-01-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix an integer underflow that leads to a null pointer dereference in 'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet could be manipulated, which could trigger an integer underflow of 'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently causes the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be bypassed, eventually leading to a dereference of the pointer 'p', which is a null pointer. Ensure that 'dma_len' is greater than 'min_seg_len'. Found by a modified version of syzkaller. KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+ #139 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 RIP: 0010:skb_add_rx_frag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: mt7601u_rx_tasklet+0xc73/0x1270 ? mt7601u_submit_rx_buf.isra.0+0x510/0x510 ? tasklet_action_common.isra.0+0x79/0x2f0 tasklet_action_common.isra.0+0x206/0x2f0 __do_softirq+0x1b5/0x880 ? tasklet_unlock+0x30/0x30 run_ksoftirqd+0x26/0x50 smpboot_thread_fn+0x34f/0x7d0 ? smpboot_register_percpu_thread+0x370/0x370 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30 Modules linked in: 88XXau(O) 88x2bu(O) ---[ end trace 57f34f93b4da0f9b ]--- RIP: 0010:skb_add_rx_frag+0x143/0x370 Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44 89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00 RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8 RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010 R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000 R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008 FS: 0000000000000000(0000) GS:ffff88811a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221229092906.2328282-1-jisoo.jang@yonsei.ac.kr
| * | wifi: orinoco: check return value of hermes_write_wordrec()Alexey Kodanev2023-01-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is currently no return check for writing an authentication type (HERMES_AUTH_SHARED_KEY or HERMES_AUTH_OPEN). It looks like it was accidentally skipped. This patch adds a return check similar to the other checks in __orinoco_hw_setup_enc() for hermes_write_wordrec(). Detected using the static analysis tool - Svace. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221227133306.201356-1-aleksei.kodanev@bell-sw.com