- Oct 12, 2022
-
-
Miquel Raynal authored
We must avoid the situation where one interface disables address filtering and AACK on the PHY while another interface expects to run with AACK and address filtering enabled. Just ignore the frames on the concerned interface if this happens. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20221007085310.503366-8-miquel.raynal@bootlin.com Signed-off-by:
Stefan Schmidt <stefan@datenfreihafen.org>
-
Miquel Raynal authored
This IEEE802154_HW_RX_DROP_BAD_CKSUM flag was only used by hwsim to reflect the fact that it would not validate the checksum (FCS). So this was only useful while the only filtering level hwsim was capable of was "NONE". Now that the driver has been improved we no longer need this flag. Signed-off-by:
-
Miquel Raynal authored
We have access to the address filters being theoretically applied, we also have access to the actual filtering level applied, so let's add a proper frame validation sequence in hwsim. Signed-off-by:
-
Miquel Raynal authored
As a first step, introduce a basic implementation for the ->set_hw_addr_filt() hook. In a second step, the values recorded here will be used to perform proper filtering during reception. Signed-off-by:
-
Alexander Aring authored
The current filtering level is set on the first interface up on a wpan phy. If we support scan functionality we need to change the filtering level on the fly on an operational phy and switching back again. This patch will move the receive mode parameter e.g. address filter and promiscuous mode to the drv_start() functionality to allow changing the receive mode on an operational phy not on first ifup only. In future this should be handled on driver layer because each hardware has it's own way to enter a specific filtering level. However this should offer to switch to mode IEEE802154_FILTERING_NONE and back to IEEE802154_FILTERING_4_FRAME_FIELDS. Only IEEE802154_FILTERING_4_FRAME_FIELDS and IEEE802154_FILTERING_NONE are somewhat supported by current hardware. All other filtering levels can be supported in future but will end in IEEE802154_FILTERING_NONE as the receive part can kind of "emulate" those receive paths by doing additional filtering routines. There are in total three filtering levels in the code: - the per-interface default level (should not be changed) - the required per-interface level (mac commands may play with it) - the actual per-PHY (hw) level that is currently in use Signed-off-by:
-
Alexander Aring authored
This patch moves all receive parameters above the drv_start() functionality to make it accessibile in the drv_start() function. Signed-off-by:
-
Miquel Raynal authored
The 802154 specification details several filtering levels in which the PHY and the MAC could be. The amount of filtering will vary if they are in promiscuous mode or in scanning mode. Otherwise they are expected to do some very basic checks, such as enforcing the frame validity. Either the PHY is able to do so, and the MAC has nothing to do, or the PHY has a lower filtering level than expected and the MAC should take over. For now we just define these levels in an enumeration. In a second time, we will add a per-PHY parameter showing the expected filtering level as well as a per device current filtering level, and will initialize all these fields. In a third time, we will use them to apply more filtering by software when the PHY is limited. Indeed, if the drivers know they cannot reach the requested level of filtering, they will overwrite the "current filtering" parameter so that it reflects what they do. Then, in the core, the expected filtering level will be used to decide whether some additional software processing is needed or not. Signed-off-by:
-
Yang Yingliang authored
dev_err() can be replace with dev_err_probe() which will check if error code is -EPROBE_DEFER. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20220915071258.678536-1-yangyingliang@huawei.com Signed-off-by:
-
- Jul 19, 2022
-
-
Jilin Yuan authored
Delete the redundant word 'was'. Signed-off-by:
Jilin Yuan <yuanjilin@cdjrlc.com> Link: https://lore.kernel.org/r/20220708151538.51483-1-yuanjilin@cdjrlc.com Signed-off-by:
-
- Jun 27, 2022
-
-
Miquel Raynal authored
The purpose of the netif_is_down() helper was to ensure that the network interface used was still up when performing the transmission. What it actually did was to check if _all_ interfaces were up. This was not noticed at that time because I did not use interfaces at all before discussing with Alexander Aring about how to handle coordinators properly. Drop the helper and call netif_running() on the right sub interface object directly. Fixes: 4f790184 ("net: mac802154: Add a warning in the slow path") Signed-off-by:
-
- Jun 14, 2022
-
-
Alexander Aring authored
We need to call wake_up() when hold_txs reaches zero. The semantic of atomic_dec_and_test() is that it returns true when it's zero. Fixes: f0feb349 ("net: mac802154: Introduce a tx queue flushing mechanism") Signed-off-by:
-
Alexander Aring authored
The semantic of atomic_dec_and_test() is to return true if zero is reached and we need call ieee802154_wake_queue() when zero is reached. Fixes: 20a19d1d ("net: mac802154: Bring the ability to hold the transmit queue") Signed-off-by:
-
- Jun 10, 2022
-
-
Miquel Raynal authored
In order to be able to detect possible conflicts between the net interface core and the ieee802154 core, let's add a warning in the slow path: we want to be sure that whenever we start an asynchronous MLME transmission (which can be fully asynchronous) the net core somehow agrees that this transmission is possible, ie. the device was not stopped. Warning in this case would allow us to track down more easily possible issues with the MLME logic if we ever get reports. Unlike in the hot path, such a situation cannot be handled. Signed-off-by:
-
Miquel Raynal authored
We should never start a transmission after the queue has been stopped. But because it might work we don't kill the function here but rather warn loudly the user that something is wrong. Set a flag when the queue should remain stopped. Reset this flag when the queue actually gets restarded. Just check this value to know if a transmission is legitimate, warn if it is not. Turn the flags variable into an unsigned long to allow the use of atomic helpers on it. Signed-off-by:
-
Miquel Raynal authored
This is the slow path, we need to wait for each command to be processed before continuing so let's introduce an helper which does the transmission and blocks until it gets notified of its asynchronous completion. This helper is going to be used when introducing scan support. Signed-off-by:
-
Miquel Raynal authored
Right now we are able to stop a queue but we have no indication if a transmission is ongoing or not. Thanks to recent additions, we can track the number of ongoing transmissions so we know if the last transmission is over. Adding on top of it an internal wait queue also allows to be woken up asynchronously when this happens. If, beforehands, we marked the queue to be held and stopped it, we end up flushing and stopping the tx queue. Thanks to this feature, we will soon be able to introduce a synchronous transmit API. Signed-off-by:
-
Miquel Raynal authored
Sometimes calling the stop queue helper is not enough because it does not hold any lock. In order to be safe and avoid racy situations when trying to (soon) sync the Tx queue, for instance before sending an MLME frame, let's now introduce an helper which actually hold the necessary locks when doing so. Suggested-by:
Alexander Aring <alex.aring@gmail.com> Signed-off-by:
-
Miquel Raynal authored
Let's rename the current Tx path to show that this is the "hot" Tx path. We will soon introduce a slower Tx path for MLME commands. Signed-off-by:
-
Miquel Raynal authored
Create a hold_txs atomic variable and increment/decrement it when relevant, ie. when we want to hold the queue or release it: currently all the "stopped" situations are suitable, but very soon we will more extensively use this feature for MLME purposes. Upon release, the atomic counter is decremented and checked. If it is back to 0, then the netif queue gets woken up. This makes the whole process fully transparent, provided that all the users of ieee802154_wake/stop_queue() now call ieee802154_hold/release_queue() instead. In no situation individual drivers should call any of these helpers manually in order to avoid messing with the counters. There are other functions more suited for this purpose which have been introduced, such as the _xmit_complete() and _xmit_error() helpers which will handle all that for them. One advantage is that, as no more drivers call the stop/wake helpers directly, we can safely stop exporting them and only declare the hold/release ones in a header only accessible to the core. Signed-off-by:
-
Miquel Raynal authored
In order to create a synchronous API for MLME command purposes, we need to be able to track the end of the ongoing transmissions. Let's introduce an atomic variable which is incremented when a transmission starts and decremented when relevant so that we know at any moment whether there is an ongoing transmission. The counter gets decremented in the following situations: - The operation is asynchronous and there was a failure during the offloading process. - The operation is synchronous and the synchronous operation failed. - The operation finished, either successfully or not. Signed-off-by:
-
Miquel Raynal authored
Before adding more logic in the error path, let's move the wake queue call there, rename the default label and create an additional one. There is no functional change. Signed-off-by:
-
Miquel Raynal authored
This entry is dedicated to synchronous transmissions done by drivers without async hook. Make this clearer that this is not a work that any driver can use by at least prefixing it with "sync_". While at it, let's enhance the comment explaining why we choose one or the other. Signed-off-by:
-
Miquel Raynal authored
There are currently two driver hooks: one is synchronous, the other is not. We cannot rely on driver implementations to provide a synchronous API (which is related to the bus medium more than a wish to have a synchronized implementation) so we are going to introduce a sync API above any kind of driver transmit function. In order to clarify what this worker is for (synchronous driver implementation), let's rename it so that people don't get bothered by the fact that their driver does not make use of the "xmit worker" which is a too generic name. Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'ieee802154-for-net-next-2022-06-09' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next Stefan Schmidt says: ==================== pull-request: ieee802154-next 2022-06-09 This is a separate pull request for 6lowpan changes. We agreed with the bluetooth maintainers to switch the trees these changing are going into from bluetooth to ieee802154. Jukka Rissanen stepped down as a co-maintainer of 6lowpan (Thanks for the work!). Alexander is staying as maintainer. Alexander reworked the nhc_id lookup in 6lowpan to be way simpler. Moved the data structure from rb to an array, which is all we need in this case. * tag 'ieee802154-for-net-next-2022-06-09' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next: MAINTAINERS: Remove Jukka Rissanen as 6lowpan maintainer net: 6lowpan: constify lowpan_nhc structures net: 6lowpan: use array for find nhc id net: 6lowpan: remove const from scalars ==================== Link: https://lore.kernel.org/r/20220609202956.1512156-1-stefan@datenfreihafen.org Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Jonathan Toppins says: ==================== bonding: netlink errors and cleanup The first patch attempts to set helpful error messages when configuring bonds via netlink. The second patch removes redundant init code for RLB mode which is already done in bond_open. ==================== Link: https://lore.kernel.org/r/cover.1654711315.git.jtoppins@redhat.com Signed-off-by:
-
Jonathan Toppins authored
Setting RLB_NULL_INDEX is not needed as this is done in bond_alb_initialize which is called by bond_open. Also reduce the number of rtnl_unlock calls by just using the standard goto cleanup path. Signed-off-by:
Jonathan Toppins <jtoppins@redhat.com> Acked-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
-
Jonathan Toppins authored
Add support for reporting errors via extack in both bond_newlink and bond_changelink. Instead of having to look in the kernel log for why an option was not correct just report the error to the user via the extack variable. What is currently reported today: ip link add bond0 type bond ip link set bond0 up ip link set bond0 type bond mode 4 RTNETLINK answers: Device or resource busy After this change: ip link add bond0 type bond ip link set bond0 up ip link set bond0 type bond mode 4 Error: unable to set option because the bond is up. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== 100GbE Intel Wired LAN Driver Updates 2022-06-08 Michal prevents setting of VF VLAN capabilities in switchdev mode and removes, not needed, specific switchdev VLAN operations. Karol converts u16 variables to unsigned int for GNSS calculations. Christophe Jaillet corrects the parameter order for a couple of devm_kcalloc() calls. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: Use correct order for the parameters of devm_kcalloc() ice: remove u16 arithmetic in ice_gnss ice: remove VLAN representor specific ops ice: don't set VF VLAN caps in switchdev ==================== Link: https://lore.kernel.org/r/20220608160757.2395729-1-anthony.l.nguyen@intel.com Signed-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: few debug refinements Adopt DEBUG_NET_WARN_ON_ONCE() or WARN_ON_ONCE() in some places where it makes sense. Add checks in napi_consume_skb() and __napi_alloc_skb() Make sure napi_get_frags() does not use page fragments for skb->head. ==================== Link: https://lore.kernel.org/r/20220608160438.1342569-1-eric.dumazet@gmail.com Signed-off-by:
-
Eric Dumazet authored
This is a follow up of commit 3226b158 ("net: avoid 32 x truesize under-estimation for tiny skbs") When/if we increase MAX_SKB_FRAGS, we better make sure the old bug will not come back. Adding a check in napi_get_frags() would be costly, even if using DEBUG_NET_WARN_ON_ONCE(). Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
Commit 6454eca8 ("net: Use lockdep_assert_in_softirq() in napi_consume_skb()") added a check in napi_consume_skb() which is a bit weak. napi_consume_skb() and __napi_alloc_skb() should only be used from BH context, not from hard irq or nmi context, otherwise we could have races. Signed-off-by:
-
Eric Dumazet authored
Remove this check from fast path unless CONFIG_DEBUG_NET=y Signed-off-by:
-
Eric Dumazet authored
Replace four WARN_ON() that have not triggered recently with DEBUG_NET_WARN_ON_ONCE(). Signed-off-by:
-
Eric Dumazet authored
sk_stream_kill_queues() has three checks which have been useful to detect kernel bugs in the past. However they are potentially a problem because they could flood the syslog. Signed-off-by:
-
Eric Dumazet authored
inet_sock_destruct() has four warnings which have been useful to point to kernel bugs in the past. However they are potentially a problem because they could flood the syslog. Signed-off-by:
-
Eric Dumazet authored
One check in dev_loopback_xmit() has not caught issues in the past. Keep it for CONFIG_DEBUG_NET=y builds only. Signed-off-by:
-
Eric Dumazet authored
Check against skb dst in socket backlog has never triggered in past years. Keep the check omly for CONFIG_DEBUG_NET=y builds. Signed-off-by:
-
Jakub Kicinski authored
Eric Dumazet says: ==================== net: adopt u64_stats_t type While KCSAN has not raised any reports yet, we should address the potential load/store tearing problem happening with per cpu stats. This series is not exhaustive, but hopefully a step in the right direction. ==================== Link: https://lore.kernel.org/r/20220608154640.1235958-1-eric.dumazet@gmail.com Signed-off-by:
-
Eric Dumazet authored
As explained in commit 316580b6 ("u64_stats: provide u64_stats_t type") we should use u64_stats_t and related accessors to avoid load/store tearing. Signed-off-by:
-
Eric Dumazet authored
As explained in commit 316580b6 ("u64_stats: provide u64_stats_t type") we should use u64_stats_t and related accessors to avoid load/store tearing. Signed-off-by:
-
