Delete the unnecessary while loop in udp_read_skb() for readability.
Additionally, since recv_actor() cannot return a value greater than
skb->len (see sk_psock_verdict_recv()), remove the redundant check.
Suggested-by: Cong Wang <cong.wang@bytedance.com>
Signed-off-by: Peilin Ye <peilin.ye@bytedance.com>
Link: https://lore.kernel.org/r/343b5d8090a3eb764068e9f1d392939e2b423747.1663909008.git.peilin.ye@bytedance.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Commit 0a28bfd4 added a metadata_dst to each tx_sc, but that's
only allocated when macsec_add_dev has run, which happens after device
registration. If the requested or computed SCI already exists, or if
linking to the lower device fails, we will panic because
metadata_dst_free can't handle NULL.

Reproducer:
    ip link add link $lower type macsec
    ip link add link $lower type macsec

Fixes: 0a28bfd4 ("net/macsec: Add MACsec skb_metadata_dst Tx Data path support")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Raed Salem <raeds@nvidia.com>
Link: https://lore.kernel.org/r/60f2a1965fe553e2cade9472407d0fafff8de8ce.1663923580.git.sd@queasysnail.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Blamed commit added a txhash parameter to tcp_v6_send_response()
but forgot to update tcp_v6_send_reset() accordingly.

Fixes: aa51b80e ("ipv6: tcp: send consistent autoflowlabel in SYN_RECV state")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20220922165036.1795862-1-eric.dumazet@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Alex Elder says:

====================
net: ipa: another set of cleanups

This series contains another set of cleanups done in preparation for
an upcoming series that reworks how IPA registers and their fields
are defined.

The first replaces the use of u32_replace_bits() with a simple
logical AND operation in two places.

The second creates a new function to encapsulate some common code,
and renames another for consistency.  The third restructures two
other functions that do similar things to make their similarity more
obvious.

The fourth defines the flag bits in a register using an enumerated
type.  And the fifth updates "ipa_reg.h" so the values assigned to
enumerated type members are aligned consistently.

The last three encapsulate the code that assigns values to a few
registers into separate functions.
====================

Link: https://lore.kernel.org/r/20220922222100.2543621-1-elder@linaro.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Create a new function that encapsulates setting the BCR, TX_CFG, and
CLKON_CFG register values during hardware configuration.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Create a new function that encapsulates setting the counter
configuration register value for versions prior to IPA v4.5.
Create another small function to represent configuring hardware
timing regardless of version.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Create a new function that encapsulates setting the register flag
that disables filter and routing table hashing for IPA v4.2.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Update a few enumerated type definitions in "ipa_reg.h" so that the
values assigned to each member align on the same column.  Where a
"TX" or "RX" (or both) comment is present, move that annotation into
a separate comment between the member name and its value.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

The backward compatibility register (BCR) has a set of bit flags
that indicate ways in which the IPA hardware should operate in a
backward compatible way.  The register is not supported starting
with IPA v4.5, and where it is supported, defined bits all have the
same numeric value.

Redefine these flags using an enumerated type, with each member's
value representing the bit position that encodes it in the BCR.
This replaces all of the single-bit field masks previously defined.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Both aggr_time_limit_encode() and hol_block_timer_encode() figure
out how to encode a millisecond time value so it can be programmed
into a register.  Rearranging them a bit can make their similarity
more obvious, with both taking essentially the same form.

To do this:
  - Return 0 immediately in aggr_time_limit_encode() if the
    microseconds value supplied is zero.
  - Reverse the test at top of aggr_time_limit_encode(), so we
    compute and return the Qtime value in the "true" block,
    and compute the result the old way otherwise.
  - Open-code (and eliminate) hol_block_timer_qtime_encode() at the
    top of hol_block_timer_encode() in the case we use Qtimer.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Create a new function ipa_qtime_val() which returns a value that
indicates what should be encoded for a register with a time field
expressed using Qtime.  Use it to factor out common code in
aggr_time_limit_encoded() and hol_block_timer_qtime_val().

Rename aggr_time_limit_encoded() and hol_block_timer_qtime_val() so
their names are both verbs ending in "encode".  Rename the "limit"
argument to the former to be "milliseconds" for consistency.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

In two spots we use u32_replace_bits() to replace a set of bits in a
register while preserving the rest.  Both of those cases just zero
the bits being replaced, and this can be done more simply without
using that function.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge tag 'linux-can-next-for-6.1-20220923' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next

Marc Kleine-Budde says:

====================
pull-request: can-next 2022-09-23

The first 2 patches are by Ziyang Xuan and optimize registration and
the sending in the CAN BCM protocol a bit.

The next 8 patches target the gs_usb driver. 7 are by me and first fix
the time hardware stamping support (added during this net-next cycle),
rename a variable, convert the usb_control_msg + manual
kmalloc()/kfree() to usb_control_msg_{send,rev}(), clean up the error
handling and add switchable termination support. The patch by Rhett
Aultman and Vasanth Sadhasivan convert the driver from
usb_alloc_coherent()/usb_free_coherent() to kmalloc()/URB_FREE_BUFFER.

The last patch is by Shang XiaoJing and removes an unneeded call to
dev_err() from the ctucanfd driver.

* tag 'linux-can-next-for-6.1-20220923' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
  can: ctucanfd: Remove redundant dev_err call
  can: gs_usb: remove dma allocations
  can: gs_usb: add switchable termination support
  can: gs_usb: gs_make_candev(): clean up error handling
  can: gs_usb: convert from usb_control_msg() to usb_control_msg_{send,recv}()
  can: gs_usb: gs_cmd_reset(): rename variable holding struct gs_can pointer to dev
  can: gs_usb: gs_can_open(): initialize time counter before starting device
  can: gs_usb: add missing lock to protect struct timecounter::cycle_last
  can: gs_usb: gs_usb_get_timestamp(): fix endpoint parameter for usb_control_msg_recv()
  can: bcm: check the result of can_send() in bcm_can_tx()
  can: bcm: registration process optimization in bcm_module_init()
====================

Link: https://lore.kernel.org/r/20220923120859.740577-1-mkl@pengutronix.deSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Antoine Tenart says:

====================
net: macsec: remove the preparation phase when offloading operations

It was reported[1] the 2-step phase offloading of MACsec operations did
not fit well and device drivers were mostly ignoring the first phase
(preparation). In addition the s/w fallback in case h/w rejected an
operation, which could have taken advantage of this design, never was
implemented and it's probably not a good idea anyway (at least
unconditionnally). So let's remove this logic which only makes the code
more complex for no advantage, before there are too many drivers
providing MACsec offloading.

This series removes the first phase (preparation) of the MACsec h/w
offloading. The modifications are split per-driver and in a way that
makes bissection working with logical steps; but I can squash some
patches if needed.

This was tested on the MSCC PHY but not on the Altantic nor mlx5e NICs.

[1] https://lore.kernel.org/all/166322893264.61080.12133865599607623050@kwain/T/
====================

Link: https://lore.kernel.org/r/20220921135118.968595-1-atenart@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>

Now that the MACsec offloading preparation phase was removed from the
MACsec core implementation as well as from drivers implementing it, we
can safely remove the flag representing it.
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Remove checks on the prepare phase as it is now unused by the MACsec
core implementation.
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Remove checks on the prepare phase as it is now unused by the MACsec
core implementation.
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Remove checks on the prepare phase as it is now unused by the MACsec
core implementation.
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

The hardware offloading in MACsec was initially supported using 2 phases.
This was proposed in the RFC as this could have allowed easier fallback
to the software implementation if the hardware did not support a feature
or had enough entries already. But this fallback wasn't implemented and
might not be a good idea after all. In addition it turned out this logic
didn't mapped well the hardware logic and device drivers were mostly
ignoring the preparation phase.

Let's remove this as it does not offer any advantage and is ignored by
drivers.
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

In preparation for removing the MACsec h/w offloading preparation phase,
make it a no-op in the Atlantic driver.
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

In preparation for removing the MACsec h/w offloading preparation phase,
make it a no-op in the MSCC phy driver.
Signed-off-by: Antoine Tenart <atenart@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

It looks like this test has been accidentally dropped when resolving
conflicts in this Makefile.

Most probably because there were 3 different patches modifying this file
in parallel:

  commit 152e8ec7 ("selftests/bonding: add a test for bonding lladdr target")
  commit bbb774d9 ("net: Add tests for bonding and team address list management")
  commit 2ffd5732 ("selftests: bonding: cause oops in bond_rr_gen_slave_id")

The first one was applied in 'net-next' while the two other ones were
recently applied in the 'net' tree.

But that's alright, easy to fix by re-adding the missing one!

Fixes: 0140a716 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net")
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Link: https://lore.kernel.org/r/20220923082306.2468081-1-matthieu.baerts@tessares.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>

devm_ioremap_resource() prints error message in itself. Remove the
dev_err call to avoid redundant error message.
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Link: https://lore.kernel.org/all/20220923095835.14647-1-shangxiaojing@huawei.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

DMA allocated buffers are a precious resource. If there is no need for
DMA allocations, then it might be worth to use non-dma allocated
buffers.

After testing the gs_usb driver with and without DMA allocation, there
does not seem to be a significant change in latency or CPU utilization
either way. Therefore, DMA allocation is not necessary and removed.

Internal buffers used within urbs were managed and freed manually.
These buffers are no longer needed to be managed by the driver. The
URB_FREE_BUFFER flag, allows for the buffers in question to be
automatically freed.
Co-developed-by: Rhett Aultman <rhett.aultman@samsara.com>
Signed-off-by: Rhett Aultman <rhett.aultman@samsara.com>
Signed-off-by: Vasanth Sadhasivan <vasanth.sadhasivan@samsara.com>
Link: https://lore.kernel.org/all/20220920154724.861093-2-rhett.aultman@samsara.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

The candleLight community is working on switchable termination support
for the candleLight firmware. As the the Linux CAN framework supports
switchable termination add this feature to the gs_usb driver.

Devices supporting the feature should set the
GS_CAN_FEATURE_TERMINATION and implement the
GS_USB_BREQ_SET_TERMINATION and GS_USB_BREQ_GET_TERMINATION control
messages.

For now the driver assumes for activated termination the standard
termination value of 120Ω.

Link: https://lore.kernel.org/all/20220923074114.662045-1-mkl@pengutronix.de
Link: https://github.com/candle-usb/candleLight_fw/issues/92
Link: https://github.com/candle-usb/candleLight_fw/pull/109
Link: https://github.com/candle-usb/candleLight_fw/pull/108
Cc: Daniel Trevitz <daniel.trevitz@wika.com>
Cc: Ryan Edwards <ryan.edwards@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Introduce a label to free the allocated candev in case of an error and
make use of if. Fix a memory leak if the extended bit timing cannot be
read. Extend the error messages to print the number of the failing
channel and the symbolic error name.

Link: https://lore.kernel.org/all/20220921193902.575416-4-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Convert the driver to use usb_control_msg_{send,recv}() instead of
usb_control_msg(). These functions allow the data to be placed on the
stack. This makes the driver a lot easier as we don't have to deal
with dynamically allocated memory.

Link: https://lore.kernel.org/all/20220921193902.575416-3-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Most of the driver uses the variable "dev" to point to the struct
gs_can. Use the same name in gs_cmd_reset(), too. Rename gsdev to dev.

Fixes: d08e973a ("can: gs_usb: Added support for the GS_USB CAN devices")
Link: https://lore.kernel.org/all/20220921193902.575416-2-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

On busy networks the CAN controller might receive CAN frames directly
after starting it but before the timecounter is setup. This will lead
to NULL pointer deref while converting the converting the CAN frame's
timestamp with the timecounter.

Close the race window by setting up the timecounter before starting
the CAN controller.

Fixes: 45dfa45f ("can: gs_usb: add RX and TX hardware timestamp support")
Link: https://lore.kernel.org/all/20220921081329.385509-1-mkl@pengutronix.de
Cc: John Whittington <git@jbrengineering.co.uk
Tested-by: John Whittington <git@jbrengineering.co.uk>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

The struct timecounter::cycle_last is a 64 bit variable, read by
timecounter_cyc2time(), and written by timecounter_read(). On 32 bit
architectures this is not atomic.

Add a spinlock to protect access to struct timecounter::cycle_last. In
the gs_usb_timestamp_read() callback the lock is dropped to execute a
sleeping synchronous USB transfer. This is safe, as the variable we
want to protect is accessed during this call.

Fixes: 45dfa45f ("can: gs_usb: add RX and TX hardware timestamp support")
Link: https://lore.kernel.org/all/20220920100416.959226-3-mkl@pengutronix.de
Cc: John Whittington <git@jbrengineering.co.uk>
Tested-by: John Whittington <git@jbrengineering.co.uk>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

The 2nd argument of usb_control_msg_recv() is the "endpoint",
usb_control_msg_recv() will internally convert the endpoint into a
pipe with usb_rcvctrlpipe().

In gs_usb_get_timestamp() not the endpoint "0" is passed, but the
pipe. This worked by accident as endpoint is a __u8 and the lowest 8
bits of the pipe are 0. Fix this copy/paste error by using the correct
endpoint of "0".

Fixes: 45dfa45f ("can: gs_usb: add RX and TX hardware timestamp support")
Link: https://lore.kernel.org/all/20220920100416.959226-2-mkl@pengutronix.de
Cc: John Whittington <git@jbrengineering.co.uk>
Tested-by: John Whittington <git@jbrengineering.co.uk>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Ziyang Xuan <william.xuanziyang@huawei.com> says:

Do some small optimization for can_bcm.

v1: https://lore.kernel.org/all/cover.1662606045.git.william.xuanziyang@huawei.com

Link: https://lore.kernel.org/all/cover.1663206163.git.william.xuanziyang@huawei.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

If can_send() fail, it should not update frames_abs counter
in bcm_can_tx(). Add the result check for can_send() in bcm_can_tx().
Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Link: https://lore.kernel.org/all/9851878e74d6d37aee2f1ee76d68361a46f89458.1663206163.git.william.xuanziyang@huawei.comAcked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Now, register_netdevice_notifier() and register_pernet_subsys() are both
after can_proto_register(). It can create CAN_BCM socket and process socket
once can_proto_register() successfully, so it is possible missing notifier
event or proc node creation because notifier or bcm proc directory is not
registered or created yet. Although this is a low probability scenario, it
is not impossible.

Move register_pernet_subsys() and register_netdevice_notifier() to the
front of can_proto_register(). In addition, register_pernet_subsys() and
register_netdevice_notifier() may fail, check their results are necessary.
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Link: https://lore.kernel.org/all/823cff0ebec33fa9389eeaf8b8ded3217c32cb38.1663206163.git.william.xuanziyang@huawei.comAcked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>

Horatiu Vultur says:

====================
net: lan966x: Add mqprio and taprio support

Add support for offloading QoS features with tc command to lan966x. The
offloaded QoS features are mqprio and taprio.

v1->v2:
- fix compilation warning
- rename lan966x_taprio_enable/disable to lan966x_taprio_add/del
====================
Signed-off-by: David S. Miller <davem@davemloft.net>

Lan966x switch supports time-based egress shaping in hardware
according to IEEE 802.1Qbv. Add support for TAS configuration on
egress port of lan966x switch.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add registers that are used by taprio to configure the HW.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Implement mqprio qdisc support using tc command.
The HW supports 8 priority queues from highest (7) to lowest (0).
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Add a define for the number of priority queues on lan966x. Because there
will be more checks for this, so instead of using hardcoded value all
over the place add a define for this.
Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

use kstrdup instead of open-coding it.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Acked-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>