The function parameter name was wrong in kdocs.

net/mac802154/util.c:27: warning: Function parameter or member 'hw' not described in 'ieee802154_wake_queue'
net/mac802154/util.c:27: warning: Excess function parameter 'local' description in 'ieee802154_wake_queue'
net/mac802154/util.c:53: warning: Function parameter or member 'hw' not described in 'ieee802154_stop_queue'
net/mac802154/util.c:53: warning: Excess function parameter 'local' description in 'ieee802154_stop_queue'

Fixing name and description.
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

We now have a fine grained filtering information so let's ensure proper
filtering in scan mode, which means that only beacons are processed.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20221019134423.877169-4-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

Save the requested filtering level in the ->set_promiscuous()
helper. The logic is: either we want to enable promiscuous mode and we
want to disable filters entirely, or we want to use the highest
filtering level by default. This is of course an assumption that only
works today, but if in the future intermediate levels (such as scan
filtering level) are implemented in the core, this logic will need to be
updated. This would imply replacing ->set_promiscuous() by something
more fine grained anyway, so we are probably safe with this assumption.

Once saved in the PIB structure, we can use this value instead of trying
to access the PHY structure to know what hardware filtering level has
been advertised.
Suggested-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20221019134423.877169-3-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

Perform the update of the PIB structure only in a single place. This way
we can have much simpler functions when updating the page, channel or
address filters. This helper will become even more useful when we will
update the ->set_promiscuous() callback to actually save the filtering
level in the PIB structure.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20221019134423.877169-2-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

This patch adds support for reading the trac register if atusb firmware
reports tx done. There is currently a feature to compare a sequence
number, if the payload is 1 it tells the driver only the sequence number
is available if it's two there is additional the trac status register as
payload.

Currently the atusb_in_good() function determines if it's a tx done or
rx done if according the payload length. This patch is doing the same
and assumes this behaviour.
Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20220905203412.1322947-10-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

With DEBUG defined, any frame received will see its MHR fields (fc and
addresses, mainly) being printed in the kernel log buffer,
unconditionally. In most cases this is fine, but in some specific cases
(like Acknowledgment frames, where both the source and destination
addressing fields are omitted), it displays garbage which is
misleading.

Only print the addressing fields when they are present, which clarifies
the logs.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20220905202724.1322046-1-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20221007085310.503366-7-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20221007085310.503366-6-miquel.raynal@bootlin.com
[stefan@datenfreihafen.org: fixup some checkpatch warnings]
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20221007085310.503366-5-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <aahringo@redhat.com>
[<miquel.raynal@bootlin.com: Add the third filtering variable]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20221007085310.503366-4-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

This patch moves all receive parameters above the drv_start()
functionality to make it accessibile in the drv_start() function.
Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20221007085310.503366-3-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20221007085310.503366-2-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

Delete the redundant word 'was'.
Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com>
Link: https://lore.kernel.org/r/20220708151538.51483-1-yuanjilin@cdjrlc.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220617192914.1275611-1-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <aahringo@redhat.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20220613043735.1039895-3-aahringo@redhat.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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: Alexander Aring <aahringo@redhat.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/r/20220613043735.1039895-2-aahringo@redhat.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-12-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-11-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-10-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-9-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-8-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-7-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-6-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-5-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-4-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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 <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-3-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Alexander Aring <aahringo@redhat.com>
Link: https://lore.kernel.org/r/20220519150516.443078-2-miquel.raynal@bootlin.comSigned-off-by: Stefan Schmidt <stefan@datenfreihafen.org>

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.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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: Jonathan Toppins <jtoppins@redhat.com>
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

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: Jakub Kicinski <kuba@kernel.org>

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 <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Remove this check from fast path unless CONFIG_DEBUG_NET=y
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Replace four WARN_ON() that have not triggered recently
with DEBUG_NET_WARN_ON_ONCE().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

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 <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>