summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-07-22wifi: mac80211: add macros to loop over active linksGregory Greenman
Add a preliminary version which will be updated later to loop over vif's and sta's active links. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: remove erroneous sband/link validationJohannes Berg
In sta_apply_parameters(), we really no longer need to check that the link or sband exists, in fact, that's harmful if link 0 doesn't exist, since then this will fail. Just remove this check, it was added for validation of the sband where used, but it's not used here, it's now only used in sta_link_apply_parameters() which has an own lookup and check. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: mlme: transmit assoc frame with address translationJohannes Berg
To transmit the association frame to the right station and with address translation, use the correct addresses there and set up the AP address in the configuration earlier so it's applied during the transmit of auth/assoc frames. Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: verify link addresses are differentJohannes Berg
When adding multiple links, verify that they all have different addresses. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: rx: track link in RX dataJohannes Berg
We'll need the link e.g. for decrypt, and shouldn't be looking it up all the time later, so track it in the RX data. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: optionally implement MLO multicast TXJohannes Berg
For drivers using software encryption for multicast TX, such as mac80211_hwsim, mac80211 needs to duplicate the multicast frames on each link, if MLO is enabled. Do this, but don't just make it dependent on the key but provide a separate flag for drivers to opt out of this. This is not very efficient, I expect that drivers will do it in firmware/hardware or at least with DMA engine assistence, so this is mostly for hwsim. To make this work, also implement the SNS11 sequence number space that an AP MLD shall have, and modify the API to the __ieee80211_subif_start_xmit() function to always require the link ID bits to be set. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: expand ieee80211_mgmt_tx() for MLOJohannes Berg
There are a couple of new things that should be possible with MLO: * selecting the link to transmit to a station by link ID, which a previous patch added to the nl80211 API * selecting the link by frequency, similarly * allowing transmittion to an MLD without specifying any channel or link ID, with MLD addresses Enable these use cases. Also fix the address comparison in client mode to use the AP (MLD) address. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: nl80211: add MLO link ID to the NL80211_CMD_FRAME TX APIJohannes Berg
Allow optionally specifying the link ID to transmit on, which can be done instead of the link frequency, on an MLD addressed frame. Both can also be omitted in which case the frame must be MLD addressed and link selection (and address translation) will be done on lower layers. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: report link ID to cfg80211 on mgmt RXJohannes Berg
For frames received on an MLD, report the link ID to userspace. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: cfg80211: report link ID in NL80211_CMD_FRAMEJohannes Berg
If given by the underlying driver, report the link ID for MLO in NL80211_CMD_FRAME. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: add hardware timestamps for RX and TXAvraham Stern
When the low level driver reports hardware timestamps for frame TX status or frame RX, pass the timestamps to cfg80211. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: cfg80211: add hardware timestamps to frame RX infoAvraham Stern
Add hardware timestamps to management frame RX info. This shall be used by drivers that support hardware timestamping for Timing measurement and Fine timing measurement action frames RX. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: cfg80211/nl80211: move rx management data into a structAvraham Stern
The functions for reporting rx management take many arguments. Collect all the arguments into a struct, which also make it easier to add more arguments if needed. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: cfg80211: add a function for reporting TX status with hardware timestampsAvraham Stern
Add a function for reporting TX status with hardware timestamps. This function shall be used for reporting the TX status of Timing measurement and Fine timing measurement action frames by devices that support reporting hardware timestamps. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: nl80211: add RX and TX timestamp attributesAvraham Stern
Add attributes for reporting hardware timestamps for management frames RX and TX. These attributes will be used for reporting hardware timestamps for Timing measurement and Fine Timing Measurement action frames, which will allow userspace applications to measure the path delay between devices and sync clocks. For TX, these attributes are used for reporting the frame RX time and the ack TX time. For TX, they are used for reporting the frame TX time and the ack RX time. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: ieee80211: add helper functions for detecting TM/FTM framesAvraham Stern
Add helper functions for detection timing measurement and fine timing measurement frames. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211_hwsim: handle links for wmediumd/virtioJohannes Berg
For wmediumd/virtio, handle both the RX channel for links, as well as the link addresses when links are added/removed. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: sta_info: fix link_sta insertionJohannes Berg
When inserting a link STA, make sure it doesn't exist first and add lockdep assertions that we cannot modify the hash table without holding the sta_mtx, so this check is really correct. Also return without hashing if the driver failed, and warn if the hashing fails, which shouldn't happen due to the check described above. Fixes: cb71f1d136a6 ("wifi: mac80211: add sta link addition/removal") Fixes: ba6ddab94fc6 ("wifi: mac80211: maintain link-sta hash table") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: mlme: fix link_sta setupJohannes Berg
We need to copy the address to both the private and public portion of the link_sta (the private one is needed for the hash table). Fix this. Fixes: bbe90107e1d9 ("wifi: mac80211: mlme: refactor link station setup") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: nl80211/mac80211: clarify link ID in control port TXJohannes Berg
Clarify the link ID behaviour in control port TX, we need it to select the link to transmit on for both MLD and non-MLD receivers, but select the link address as the SA only if the receiver is not an MLD. Fixes: 67207bab9341 ("wifi: cfg80211/mac80211: Support control port TX from specific link") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: return error from control port TX for dropsJohannes Berg
If the frame is going to be dropped anyway because ieee80211_lookup_ra_sta() returned an error (and even though it's a bit racy, it will likely continue to do so), return the error out instead of just silently dropping the frame. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: nl80211: require MLD address on link STA add/modifyJohannes Berg
We always need the MLD address and link ID to add or modify the link STA, so require it in the API. Fixes: 577e5b8c3924 ("wifi: cfg80211: add API to add/modify/remove a link station") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: more station handling sanity checksJohannes Berg
Add more sanity checks to the API handling, we shouldn't be able to create a station without links, nor should we be able to add a link to a station that wasn't created as an MLD with links in the first place. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: fix link sta hash table handlingJohannes Berg
There are two issues here: we unhash the link stations only directly before freeing the station they belong to, and we also don't unhash all the links correctly in all cases. Fix these issues. Fixes: ba6ddab94fc6 ("wifi: mac80211: maintain link-sta hash table") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: validate link address doesn't changeJohannes Berg
When modifying a link station, validate that the link address doesn't change, except the first time the link is created. Fixes: b95eb7f0eee4 ("wifi: cfg80211/mac80211: separate link params from station params") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: mlme: set sta.mlo to mlo stateJohannes Berg
At this point, we've already changed link_id to be zero for a non-MLO connection, so use the 'mlo' variable rather than link ID to determine the MLO status of the station. Fixes: bd363ee53302 ("wifi: mac80211: mlme: set sta.mlo correctly") Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: fast-xmit: handle non-MLO clientsJohannes Berg
If there's a non-MLO client, the A2 must be set to the BSSID of the link since no translation will happen in lower layers and it's needed that way for encryption. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211_hwsim: fix address translation for MLOJohannes Berg
There are two issues here: we need to do the translation even in case mac80211 selected a link, and we should only translate the A3 if it's the BSSID. Fix both. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: fix RX MLD address translationJohannes Berg
We should only translate addr3 here if it's the BSSID. Fixes: 42fb9148c078 ("wifi: mac80211: do link->MLD address translation on RX") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: fix NULL pointer deref with non-MLD STAJohannes Berg
If we have a non-MLD STA on an AP MLD, we crash while adding the station. Fix that, in this case we need to use the STA's address also on the link data structure. Fixes: f36fe0a2df03 ("wifi: mac80211: fix up link station creation/insertion") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: mlme: fix override calculationJohannes Berg
In my previous changes here, I neglected to take the old conn_flags into account that might still be present from the authentication, and thus ieee80211_setup_assoc_link() can misbehave, as well as the override calculation being wrong. Fix that by ORing in the old flags. Fixes: 1845c1d4a455 ("wifi: mac80211: mlme: refactor assoc link setup") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22wifi: mac80211: tx: use AP address in some places for MLOJohannes Berg
In a few places we need to use the AP (MLD) address, not the deflink BSSID, the link address translation will happen later. To make that work properly for fast-xmit, set up the ap_addr in the vif.cfg earlier. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-07-22ARM: cns3xxx: add CONFIG_UNUSED_BOARD_FILES dependencyArnd Bergmann
Krzysztof Halasa has kept the cns3xxx platform working for a long time but has moved away from working on it. The OpenWRT port was dropped in 2020, and support for the Gateworks Laguna platform never made it into the mainline kernel, which only supports the reference design. Further, the ARM11MPCore has an unresolved issue with instruction cache coherency, and removing support for the remaining platforms using this core would be the easiest solution. Mark the entire platform as unused now, to be removed in early 2023 if no users show up. Cc: Krzysztof Halasa <khalasa@piap.pl> Link: https://lore.kernel.org/lkml/20210616152326.GG22278@shell.armlinux.org.uk/ Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-22ARM: iop32x: mark as unusedArnd Bergmann
The iop32x platform has recently been converted to be part of the multiplatform configuration, and it should be possible to keep it alive for longer by making it boot from devicetree like we did for the related ixp4xx platform. However, it appears that no users remain at this point, so just mark the entire platform depending on CONFIG_UNUSED_BOARD_FILES, with the intention of removing it in early 2023. If any users remain, please speak up now. Cc: Lennert Buytenhek <buytenh@wantstofly.org> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-22ARM: s3c: mark most board files as unusedArnd Bergmann
The s3c24xx platform is already scheduled for removal in early 2023, with s3c64xx meeting the same fate a year later. Most of the s3c64xx board files appear to be unused, as the better maintained ones already got converted to DT. The main exception is the Wolfson Cragganmore board, which remains in use as the reference design for Wolfson/Cirrus devices. As the other boards get removed, this one stays around along with the DT based machines. The s3c6400_defconfig file now disables the unused boards, while the s3c24xx defconfig files all turn on CONFIG_UNUSED_BOARD_FILES to remain usable. Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Alim Akhtar <alim.akhtar@samsung.com> Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-22ARM: omap1: add Kconfig dependencies for unused boardsArnd Bergmann
Legacy board files with no known users are planned to get removed in early 2023, and this covers the majority of the omap1 boards as well. According to Tony, the actual users are all on OSK, Nokia770, and AMS-Delta. Additionally, the sx1 and palmte boards are supported by qemu, which is convenient for testing, so all five stay around past the initial board removal. As omap1 is now part of the multiplatform build and uses the common-clk framework, it has become easier to convert these to use devicetree based booting in the future. Cc: Janusz Krzysztofik <jmkrzyszt@gmail.com> Cc: Tony Lindgren <tony@atomide.com> Cc: linux-omap@vger.kernel.org Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-22ARM: sa1100: mark most boards as unusedArnd Bergmann
Most Arm board files are unused and will be removed in early 2023 if no remaining users show up. For the sa1100 platform, the machines that are still in use are: - Russell's Assabet development board - Linus' H3600 iPaq PocketPC - Collie as the only qemu-supported board, to allow testing by others All remaining sa1100 boards are marked to depend on CONFIG_UNUSED_BOARD_FILES to give potential users a last chance to speak up. Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com> Cc: Russell King <linux@armlinux.org.uk> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-07-22net: add missing includes and forward declarations under net/Jakub Kicinski
This patch adds missing includes to headers under include/net. All these problems are currently masked by the existing users including the missing dependency before the broken header. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22caif: Fix bitmap data type in "struct caifsock"Christophe JAILLET
Bitmap are "unsigned long", so use it instead of a "u32" to make things more explicit. While at it, remove some useless cast (and leading spaces) when using the bitmap API. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22Merge branch 'sfc-E100-VF-respresenters'David S. Miller
Edward Cree says: ==================== sfc: VF representors for EF100 This series adds representor netdevices for EF100 VFs, as a step towards supporting TC offload and vDPA usecases in future patches. In this first series is basic netdevice creation and packet TX; the following series will add the RX path. v3: dropped massive mcdi_pcol.h patch which was applied separately. v2: converted comments on struct efx_nic members added in patch #4 to kernel-doc (Jakub). While at it, also gave struct efx_rep its own kdoc since several members had comments on them. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22sfc: attach/detach EF100 representors along with their owning PFEdward Cree
Since representors piggy-back on the PF's queues for TX, they can only accept new TXes while the PF is up. Thus, any operation which detaches the PF must first detach all its VFreps. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22sfc: hook up ef100 representor TXEdward Cree
Implement .ndo_start_xmit() by calling into the parent PF's TX path. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22sfc: support passing a representor to the EF100 TX pathEdward Cree
A non-null efv in __ef100_enqueue_skb() indicates that the packet is from that representor, should be transmitted with a suitable option descriptor (to instruct the switch to deliver it to the representee), and should not be accounted to the parent PF's stats or BQL. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22sfc: determine representee m-port for EF100 representorsEdward Cree
An MAE port, or m-port, is a port (source/destination for traffic) on the Match-Action Engine (the internal switch on EF100). Representors will use their representee's m-port for two purposes: as a destination override on TX from the representor, and as a source match in 'default rules' to steer representee traffic (when not matched by e.g. a TC flower rule) to representor RX via the parent PF's receive queue. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22sfc: phys port/switch identification for ef100 repsEdward Cree
Requires storing VF index in struct efx_rep. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22sfc: add basic ethtool ops to ef100 repsEdward Cree
Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22sfc: add skeleton ef100 VF representorsEdward Cree
No net_device_ops yet, just a placeholder netdev created per VF. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22sfc: detect ef100 MAE admin privilege/capability at probe timeEdward Cree
One PCIe function per network port (more precisely, per m-port group) is responsible for configuring the Match-Action Engine which performs switching and packet modification in the slice to support flower/OVS offload. The GRP_MAE bit in the privilege mask indicates whether a given function has this capability. At probe time, call MCDIs to read the calling function's privilege mask, and store the GRP_MAE bit in a new ef100_nic_data member. Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22sfc: update EF100 register descriptionsEdward Cree
Signed-off-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-22ping: support ipv6 ping socket flow labelsAlan Brady
Ping sockets don't appear to make any attempt to preserve flow labels created and set by userspace using IPV6_FLOWINFO_SEND. Instead they are clobbered by autolabels (if enabled) or zero. Grab the flowlabel out of the msghdr similar to how rawv6_sendmsg does it and move the memset up so it doesn't get zeroed after. Signed-off-by: Alan Brady <alan.brady@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>