]> Git Repo - linux.git/log
linux.git
23 months agocan: kvaser_pciefd: Disable interrupts in probe error path
Jimmy Assarsson [Tue, 16 May 2023 13:43:18 +0000 (15:43 +0200)]
can: kvaser_pciefd: Disable interrupts in probe error path

Disable interrupts in error path of probe function.

Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
Cc: [email protected]
Signed-off-by: Jimmy Assarsson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: kvaser_pciefd: Do not send EFLUSH command on TFD interrupt
Jimmy Assarsson [Tue, 16 May 2023 13:43:17 +0000 (15:43 +0200)]
can: kvaser_pciefd: Do not send EFLUSH command on TFD interrupt

Under certain circumstances we send two EFLUSH commands, resulting in two
EFLUSH ack packets, while only expecting a single EFLUSH ack.
This can cause the driver Tx flush completion to get out of sync.

To avoid this problem, don't enable the "Transmit buffer flush done" (TFD)
interrupt and remove the code handling it.
Now we only send EFLUSH command after receiving status packet with
"Init detected" (IDET) bit set.

Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
Cc: [email protected]
Signed-off-by: Jimmy Assarsson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: kvaser_pciefd: Empty SRB buffer in probe
Jimmy Assarsson [Tue, 16 May 2023 13:43:16 +0000 (15:43 +0200)]
can: kvaser_pciefd: Empty SRB buffer in probe

Empty the "Shared receive buffer" (SRB) in probe, to assure we start in a
known state, and don't process any irrelevant packets.

Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
Cc: [email protected]
Signed-off-by: Jimmy Assarsson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: kvaser_pciefd: Call request_irq() before enabling interrupts
Jimmy Assarsson [Tue, 16 May 2023 13:43:15 +0000 (15:43 +0200)]
can: kvaser_pciefd: Call request_irq() before enabling interrupts

Make sure the interrupt handler is registered before enabling interrupts.

Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
Cc: [email protected]
Signed-off-by: Jimmy Assarsson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: kvaser_pciefd: Clear listen-only bit if not explicitly requested
Jimmy Assarsson [Tue, 16 May 2023 13:43:14 +0000 (15:43 +0200)]
can: kvaser_pciefd: Clear listen-only bit if not explicitly requested

The listen-only bit was never cleared, causing the controller to
always use listen-only mode, if previously set.

Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
Cc: [email protected]
Signed-off-by: Jimmy Assarsson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: kvaser_pciefd: Set CAN_STATE_STOPPED in kvaser_pciefd_stop()
Jimmy Assarsson [Tue, 16 May 2023 13:43:13 +0000 (15:43 +0200)]
can: kvaser_pciefd: Set CAN_STATE_STOPPED in kvaser_pciefd_stop()

Set can.state to CAN_STATE_STOPPED in kvaser_pciefd_stop().
Without this fix, wrong CAN state was repported after the interface was
brought down.

Fixes: 26ad340e582d ("can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices")
Cc: [email protected]
Signed-off-by: Jimmy Assarsson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agowifi: b43: fix incorrect __packed annotation
Arnd Bergmann [Tue, 16 May 2023 18:34:22 +0000 (20:34 +0200)]
wifi: b43: fix incorrect __packed annotation

clang warns about an unpacked structure inside of a packed one:

drivers/net/wireless/broadcom/b43/b43.h:654:4: error: field data within 'struct b43_iv' is less aligned than 'union (unnamed union at /home/arnd/arm-soc/drivers/net/wireless/broadcom/b43/b43.h:651:2)' and is usually due to 'struct b43_iv' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access]

The problem here is that the anonymous union has the default alignment
from its members, apparently because the original author mixed up the
placement of the __packed attribute by placing it next to the struct
member rather than the union definition. As the struct itself is
also marked as __packed, there is no need to mark its members, so just
move the annotation to the inner type instead.

As Michael noted, the same problem is present in b43legacy, so
change both at the same time.

Acked-by: Michael Büsch <[email protected]>
Reported-by: kernel test robot <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Larry Finger <[email protected]>
Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
23 months agowifi: rtw88: sdio: Always use two consecutive bytes for word operations
Martin Blumenstingl [Mon, 15 May 2023 19:50:43 +0000 (21:50 +0200)]
wifi: rtw88: sdio: Always use two consecutive bytes for word operations

The Allwinner sunxi-mmc controller cannot handle word (16 bit)
transfers. So and sdio_{read,write}w fails with messages like the
following example using an RTL8822BS (but the same problems were also
observed with RTL8822CS and RTL8723DS chips):
  rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13
  sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2
  sunxi-mmc 4021000.mmc: map DMA failed
  rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22

Use two consecutive single byte accesses for word operations instead. It
turns out that upon closer inspection this is also what the vendor
driver does, even though it does have support for sdio_{read,write}w. So
we can conclude that the rtw88 chips do support word access but only on
SDIO controllers that also support it. Since there's no way to detect if
the controller supports word access or not the rtw88 sdio driver
switches to the easiest approach: avoiding word access.

Reported-by: Larry Finger <[email protected]>
Closes: https://lore.kernel.org/linux-wireless/[email protected]/
Reported-by: Rudi Heitbaum <[email protected]>
Link: https://github.com/LibreELEC/LibreELEC.tv/pull/7837#issue-1708469467
Fixes: 65371a3f14e7 ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets")
Reviewed-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
23 months agoMerge tag 'linux-can-next-for-6.5-20230515' of git://git.kernel.org/pub/scm/linux...
Jakub Kicinski [Wed, 17 May 2023 03:58:58 +0000 (20:58 -0700)]
Merge tag 'linux-can-next-for-6.5-20230515' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next

Marc Kleine-Budde says:

====================
pull-request: can-next 2023-05-15

The 1st patch is by Ji-Ze Hong and adds support for the Fintek F81604
USB-CAN adapter.

Jiapeng Chong's patch removes unnecessary dev_err() functions from the
bxcan driver.

The next patch is by me an makes a CAN internal header file self
contained.

The remaining 19 patches are by Uwe Kleine-König, they all convert the
platform driver remove callback to return void.

* tag 'linux-can-next-for-6.5-20230515' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: (22 commits)
  can: xilinx: Convert to platform remove callback returning void
  can: ti_hecc: Convert to platform remove callback returning void
  can: sun4i_can: Convert to platform remove callback returning void
  can: softing: Convert to platform remove callback returning void
  can: sja1000_platform: Convert to platform remove callback returning void
  can: sja1000_isa: Convert to platform remove callback returning void
  can: rcar: Convert to platform remove callback returning void
  can: mscan: mpc5xxx_can: Convert to platform remove callback returning void
  can: m_can: Convert to platform remove callback returning void
  can: janz-ican3: Convert to platform remove callback returning void
  can: ifi_canfd: Convert to platform remove callback returning void
  can: grcan: Convert to platform remove callback returning void
  can: flexcan: Convert to platform remove callback returning void
  can: ctucanfd: Convert to platform remove callback returning void
  can: length: make header self contained
  can: cc770_platform: Convert to platform remove callback returning void
  can: bxcan: Remove unnecessary print function dev_err()
  can: cc770_isa: Convert to platform remove callback returning void
  can: usb: f81604: add Fintek F81604 support
  can: c_can: Convert to platform remove callback returning void
  ...
====================

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
23 months agoMerge tag 'ipsec-2023-05-16' of git://git.kernel.org/pub/scm/linux/kernel/git/klasser...
Jakub Kicinski [Wed, 17 May 2023 03:52:34 +0000 (20:52 -0700)]
Merge tag 'ipsec-2023-05-16' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec

Steffen Klassert says:

====================
pull request (net): ipsec 2023-05-16

1) Don't check the policy default if we have an allow
   policy. Fix from Sabrina Dubroca.

2) Fix netdevice refount usage on offload.
   From Leon Romanovsky.

3) Use netdev_put instead of dev_puti to correctly release
   the netdev on failure in xfrm_dev_policy_add.
   From Leon Romanovsky.

4) Revert "Fix XFRM-I support for nested ESP tunnels"
   This broke Netfilter policy matching.
   From Martin Willi.

5) Reject optional tunnel/BEET mode templates in outbound policies
   on netlink and pfkey sockets. From Tobias Brunner.

6) Check if_id in inbound policy/secpath match to make
   it symetric to the outbound codepath.
   From Benedict Wong.

* tag 'ipsec-2023-05-16' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec:
  xfrm: Check if_id in inbound policy/secpath match
  af_key: Reject optional tunnel/BEET mode templates in outbound policies
  xfrm: Reject optional tunnel/BEET mode templates in outbound policies
  Revert "Fix XFRM-I support for nested ESP tunnels"
  xfrm: Fix leak of dev tracker
  xfrm: release all offloaded policy memory
  xfrm: don't check the default policy if the policy allows the packet
====================

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
23 months agoMerge tag 'linux-can-fixes-for-6.4-20230515' of git://git.kernel.org/pub/scm/linux...
Jakub Kicinski [Wed, 17 May 2023 03:49:42 +0000 (20:49 -0700)]
Merge tag 'linux-can-fixes-for-6.4-20230515' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can

Marc Kleine-Budde says:

====================
pull-request: can 2023-05-15

The first 2 patches are by Oliver Hartkopp and allow the
MSG_CMSG_COMPAT flag for isotp and j1939.

The next patch is by Oliver Hartkopp, too and adds missing CAN XL
support in can_put_echo_skb().

Geert Uytterhoeven's patch let's the bxcan driver depend on
ARCH_STM32.

The last 5 patches are from Dario Binacchi and also affect the bxcan
driver. The bxcan driver hit mainline with v6.4-rc1 and was originally
written for IP cores containing 2 CAN interfaces with shared
resources. Dario's series updates the DT bindings and driver to
support IP cores with a single CAN interface instance as well as
adding the bxcan to the stm32f746's device tree.

* tag 'linux-can-fixes-for-6.4-20230515' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
  ARM: dts: stm32: add CAN support on stm32f746
  can: bxcan: add support for single peripheral configuration
  ARM: dts: stm32: add pin map for CAN controller on stm32f7
  ARM: dts: stm32f429: put can2 in secondary mode
  dt-bindings: net: can: add "st,can-secondary" property
  can: CAN_BXCAN should depend on ARCH_STM32
  can: dev: fix missing CAN XL support in can_put_echo_skb()
  can: j1939: recvmsg(): allow MSG_CMSG_COMPAT flag
  can: isotp: recvmsg(): allow MSG_CMSG_COMPAT flag
====================

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
23 months agoRevert "net: Remove low_thresh in ip defrag"
Jakub Kicinski [Wed, 17 May 2023 03:41:12 +0000 (20:41 -0700)]
Revert "net: Remove low_thresh in ip defrag"

This reverts commit b2cbac9b9b28730e9e53be20b6cdf979d3b9f27e.

We have multiple reports of obvious breakage from this patch.

Reported-by: Ido Schimmel <[email protected]>
Link: https://lore.kernel.org/all/ZGIRWjNcfqI8yY8W@shredder/
Link: https://lore.kernel.org/all/CADJHv_sDK=0RrMA2FTZQV5fw7UQ+qY=HG21Wu5qb0V9vvx5w6A@mail.gmail.com/
Reported-by: [email protected]
Reported-by: [email protected]
Fixes: b2cbac9b9b28 ("net: Remove low_thresh in ip defrag")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
23 months agodevlink: Fix crash with CONFIG_NET_NS=n
Ido Schimmel [Mon, 15 May 2023 16:29:25 +0000 (19:29 +0300)]
devlink: Fix crash with CONFIG_NET_NS=n

'__net_initdata' becomes a no-op with CONFIG_NET_NS=y, but when this
option is disabled it becomes '__initdata', which means the data can be
freed after the initialization phase. This annotation is obviously
incorrect for the devlink net device notifier block which is still
registered after the initialization phase [1].

Fix this crash by removing the '__net_initdata' annotation.

[1]
general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] PREEMPT SMP
CPU: 3 PID: 117 Comm: (udev-worker) Not tainted 6.4.0-rc1-custom-gdf0acdc59b09 #64
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc37 04/01/2014
RIP: 0010:notifier_call_chain+0x58/0xc0
[...]
Call Trace:
 <TASK>
 dev_set_mac_address+0x85/0x120
 dev_set_mac_address_user+0x30/0x50
 do_setlink+0x219/0x1270
 rtnl_setlink+0xf7/0x1a0
 rtnetlink_rcv_msg+0x142/0x390
 netlink_rcv_skb+0x58/0x100
 netlink_unicast+0x188/0x270
 netlink_sendmsg+0x214/0x470
 __sys_sendto+0x12f/0x1a0
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0x38/0x80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fixes: e93c9378e33f ("devlink: change per-devlink netdev notifier to static one")
Reported-by: Marek Szyprowski <[email protected]>
Closes: https://lore.kernel.org/netdev/[email protected]/
Tested-by: Marek Szyprowski <[email protected]>
Signed-off-by: Ido Schimmel <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
23 months agoMerge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf...
Jakub Kicinski [Wed, 17 May 2023 02:50:05 +0000 (19:50 -0700)]
Merge tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next

Daniel Borkmann says:

====================
pull-request: bpf-next 2023-05-16

We've added 57 non-merge commits during the last 19 day(s) which contain
a total of 63 files changed, 3293 insertions(+), 690 deletions(-).

The main changes are:

1) Add precision propagation to verifier for subprogs and callbacks,
   from Andrii Nakryiko.

2) Improve BPF's {g,s}setsockopt() handling with wrong option lengths,
   from Stanislav Fomichev.

3) Utilize pahole v1.25 for the kernel's BTF generation to filter out
   inconsistent function prototypes, from Alan Maguire.

4) Various dyn-pointer verifier improvements to relax restrictions,
   from Daniel Rosenberg.

5) Add a new bpf_task_under_cgroup() kfunc for designated task,
   from Feng Zhou.

6) Unblock tests for arm64 BPF CI after ftrace supporting direct call,
   from Florent Revest.

7) Add XDP hint kfunc metadata for RX hash/timestamp for igc,
   from Jesper Dangaard Brouer.

8) Add several new dyn-pointer kfuncs to ease their usability,
   from Joanne Koong.

9) Add in-depth LRU internals description and dot function graph,
   from Joe Stringer.

10) Fix KCSAN report on bpf_lru_list when accessing node->ref,
    from Martin KaFai Lau.

11) Only dump unprivileged_bpf_disabled log warning upon write,
    from Kui-Feng Lee.

12) Extend test_progs to directly passing allow/denylist file,
    from Stephen Veiss.

13) Fix BPF trampoline memleak upon failure attaching to fentry,
    from Yafang Shao.

14) Fix emitting struct bpf_tcp_sock type in vmlinux BTF,
    from Yonghong Song.

* tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (57 commits)
  bpf: Fix memleak due to fentry attach failure
  bpf: Remove bpf trampoline selector
  bpf, arm64: Support struct arguments in the BPF trampoline
  bpftool: JIT limited misreported as negative value on aarch64
  bpf: fix calculation of subseq_idx during precision backtracking
  bpf: Remove anonymous union in bpf_kfunc_call_arg_meta
  bpf: Document EFAULT changes for sockopt
  selftests/bpf: Correctly handle optlen > 4096
  selftests/bpf: Update EFAULT {g,s}etsockopt selftests
  bpf: Don't EFAULT for {g,s}setsockopt with wrong optlen
  libbpf: fix offsetof() and container_of() to work with CO-RE
  bpf: Address KCSAN report on bpf_lru_list
  bpf: Add --skip_encoding_btf_inconsistent_proto, --btf_gen_optimized to pahole flags for v1.25
  selftests/bpf: Accept mem from dynptr in helper funcs
  bpf: verifier: Accept dynptr mem as mem in helpers
  selftests/bpf: Check overflow in optional buffer
  selftests/bpf: Test allowing NULL buffer in dynptr slice
  bpf: Allow NULL buffers in bpf_dynptr_slice(_rw)
  selftests/bpf: Add testcase for bpf_task_under_cgroup
  bpf: Add bpf_task_under_cgroup() kfunc
  ...
====================

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
23 months agomac80211_hwsim: fix memory leak in hwsim_new_radio_nl
Zhengchao Shao [Mon, 15 May 2023 09:22:27 +0000 (17:22 +0800)]
mac80211_hwsim: fix memory leak in hwsim_new_radio_nl

When parse_pmsr_capa failed in hwsim_new_radio_nl, the memory resources
applied for by pmsr_capa are not released. Add release processing to the
incorrect path.

Fixes: 92d13386ec55 ("mac80211_hwsim: add PMSR capability support")
Reported-by: [email protected]
Signed-off-by: Zhengchao Shao <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: Add locking to the rate read flow
Ariel Malamud [Sun, 14 May 2023 09:15:55 +0000 (12:15 +0300)]
wifi: iwlwifi: mvm: Add locking to the rate read flow

The rs_drv_get_rate flow reads the lq_sta to return the optimal rate
for tx frames. This read flow is not protected thereby leaving
a small window, a few instructions wide, open to contention by an
asynchronous rate update. Indeed this race condition was hit and the
update occurred in the middle of the read.

Fix this by locking the lq_sta struct during read.

Signed-off-by: Ariel Malamud <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.b52c9ed5c379.I15290b78e0d966c1b68278263776ca9de841d5fe@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: Don't use valid_links to iterate sta links
Miri Korenblit [Sun, 14 May 2023 09:15:54 +0000 (12:15 +0300)]
wifi: iwlwifi: Don't use valid_links to iterate sta links

This bitmap equals to zero when in a non-MLO mode, and then we won't
be iterating on any link. Use for_each_sta_active_link() instead, as
it handles also the case of non-MLO mode.

Signed-off-by: Miri Korenblit <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.f32a8c08730a.Ib02248cd0b7f2bc885f91005c3c110dd027f9dcd@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: don't trust firmware n_channels
Johannes Berg [Sun, 14 May 2023 09:15:53 +0000 (12:15 +0300)]
wifi: iwlwifi: mvm: don't trust firmware n_channels

If the firmware sends us a corrupted MCC response with
n_channels much larger than the command response can be,
we might copy far too much (uninitialized) memory and
even crash if the n_channels is large enough to make it
run out of the one page allocated for the FW response.

Fix that by checking the lengths. Doing a < comparison
would be sufficient, but the firmware should be doing
it correctly, so check more strictly.

Fixes: dcaf9f5ecb6f ("iwlwifi: mvm: add MCC update FW API")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.d7b233139eb4.I51fd319df8e9d41881fc8450e83d78049518a79a@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: fix OEM's name in the tas approved list
Alon Giladi [Sun, 14 May 2023 09:15:52 +0000 (12:15 +0300)]
wifi: iwlwifi: mvm: fix OEM's name in the tas approved list

Fix a spelling mistake.

Fixes: 2856f623ce48 ("iwlwifi: mvm: Add list of OEMs allowed to use TAS")
Signed-off-by: Alon Giladi <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.4090de6d1878.If9391ef6da78f1b2cc5eb6cb8f6965816bb7a7f5@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: fix OEM's name in the ppag approved list
Alon Giladi [Sun, 14 May 2023 09:15:51 +0000 (12:15 +0300)]
wifi: iwlwifi: fix OEM's name in the ppag approved list

Fix a spelling mistake.

Fixes: e8e10a37c51c ("iwlwifi: acpi: move ppag code from mvm to fw/acpi")
Signed-off-by: Alon Giladi <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.fdd07f36a8bf.I223e5fb16ab5c95d504c3fdaffd0bd70affad1c2@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: fix initialization of a return value
Mukesh Sisodiya [Sun, 14 May 2023 09:15:50 +0000 (12:15 +0300)]
wifi: iwlwifi: mvm: fix initialization of a return value

In iwl_mvm_mld_update_sta(), if the flow doesn't enter
for_each_sta_active_link(), the default value is returned.
Set this default to -EINVAL instead of 0 to better reflect
this.

Signed-off-by: Mukesh Sisodiya <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.98b7e3aacf0b.I2fc274dd7e374ef7fac8e26d71c9cd73323da665@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: fix access to fw_id_to_mac_id
Gregory Greenman [Sun, 14 May 2023 09:15:49 +0000 (12:15 +0300)]
wifi: iwlwifi: mvm: fix access to fw_id_to_mac_id

RCU protected fw_id_to_mac_id can be initialized with either
an error code or NULL. Thus, after dereferencing need to check
the value with IS_ERR_OR_NULL() and not only that it is not NULL.
Fix it.

Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.ec5f2880e81c.Ifa8c0f451df2835bde800f5c3670cc46238a3bd8@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: fw: fix DBGI dump
Johannes Berg [Sun, 14 May 2023 09:15:48 +0000 (12:15 +0300)]
wifi: iwlwifi: fw: fix DBGI dump

The DBGI dump is (unsurprisingly) of type DBGI, not SRAM.
This leads to bad register accesses because the union is
built differently, there's no allocation ID, and thus the
allocation ID ends up being 0x8000.

Note that this was already wrong for DRAM vs. SMEM since
they use different parts of the union, but the allocation
ID is at the same place, so it worked.

Fix all of this but set the allocation ID in a way that
the offset calculation ends up without any offset.

Fixes: 34bc27783a31 ("iwlwifi: yoyo: fix DBGI_SRAM ini dump header.")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.19a302ae4c65.I12272599f7c1930666157b9d5e7f81fe9ec4c421@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: fix number of concurrent link checks
Johannes Berg [Sun, 14 May 2023 09:15:47 +0000 (12:15 +0300)]
wifi: iwlwifi: mvm: fix number of concurrent link checks

The concurrent link checks need to correctly differentiate
between AP and non-AP, fix that.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.992b2f981ef6.I7d386c19354e9be39c4822f436dd22c93422b660@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: fix cancel_delayed_work_sync() deadlock
Johannes Berg [Sun, 14 May 2023 09:15:46 +0000 (12:15 +0300)]
wifi: iwlwifi: mvm: fix cancel_delayed_work_sync() deadlock

Lockdep points out that we can deadlock here by calling
cancel_delayed_work_sync() because that might be already
running and gotten interrupted by the NAPI soft-IRQ.
Even just calling something that can sleep is wrong in
this context though.

Luckily, it doesn't even really matter since the things
we need to do are idempotent, so just drop the _sync().

Fixes: e5d153ec54f0 ("iwlwifi: mvm: fix CSA AP side")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.b1813c823b4d.I9d20cc06d24fa40b6774d3dd95ea5e2bf8dd015b@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: don't double-init spinlock
Johannes Berg [Sun, 14 May 2023 09:15:45 +0000 (12:15 +0300)]
wifi: iwlwifi: mvm: don't double-init spinlock

We don't need to (and shouldn't) initialize the spinlock
during HW restart that was already initialized, so move
that into the correct if block. Since then we have two
consecutive if statements with the same (though inverted)
condition, unify those as well.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.221c22cfdf4e.I2e30113ef4bd8cb5bd9e1a69e52a95671914961c@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: always free dup_data
Johannes Berg [Sun, 14 May 2023 09:15:44 +0000 (12:15 +0300)]
wifi: iwlwifi: mvm: always free dup_data

There are some assertions in the STA removal code that can
fail, and in that case we may leak memory since we skip
the freeing.

Fix this by freeing the dup_data earlier in the function,
we already have a check for when we free the station, and
this we don't need to do it with and without MLD API, so
it's a win all around.

Fixes: a571f5f635ef ("iwlwifi: mvm: add duplicate packet detection per rx queue")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230514120631.173938681d72.Iff4b55fc52943825d6e3e28d78a24b155ea5cd22@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: mac80211: recalc chanctx mindef before assigning
Johannes Berg [Thu, 4 May 2023 13:45:04 +0000 (16:45 +0300)]
wifi: mac80211: recalc chanctx mindef before assigning

When we allocate a new channel context, or find an existing one
that is compatible, we currently assign it to a link before its
mindef is updated. This leads to strange situations, especially
in link switching where you switch to an 80 MHz link and expect
it to be active immediately, but the mindef is still configured
to 20 MHz while assigning.  Also, it's strange that the chandef
passed to the assign method's argument is wider than the one in
the context.

Fix this by calculating the mindef with the new link considered
before calling the driver.

In particular, this fixes an iwlwifi problem during link switch
where the firmware would assert because the (link) station that
was added for the AP is configured to transmit at a bandwidth
that's wider than the channel context that it's configured on.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: mac80211: consider reserved chanctx for mindef
Johannes Berg [Thu, 4 May 2023 13:45:03 +0000 (16:45 +0300)]
wifi: mac80211: consider reserved chanctx for mindef

When a chanctx is reserved for a new vif and we recalculate
the minimal definition for it, we need to consider the new
interface it's being reserved for before we assign it, so it
can be used directly with the correct min channel width.

Fix the code to - optionally - consider that, and use that
option just before doing the reassignment.

Also, when considering channel context reservations, we
should only consider the one link we're currently working with.
Change the boolean argument to a link pointer to do that.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: mac80211: simplify chanctx allocation
Johannes Berg [Thu, 4 May 2023 13:45:02 +0000 (16:45 +0300)]
wifi: mac80211: simplify chanctx allocation

There's no need to call ieee80211_recalc_chanctx_min_def()
since it cannot and won't call the driver anyway; just use
_ieee80211_recalc_chanctx_min_def() instead.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: mac80211: Abort running color change when stopping the AP
Michael Lee [Thu, 4 May 2023 08:04:41 +0000 (16:04 +0800)]
wifi: mac80211: Abort running color change when stopping the AP

When stopping the AP, there might be a color change in progress. It
should be deactivated here, or the driver might later finalize a color
change on a stopped AP.

Fixes: 5f9404abdf2a (mac80211: add support for BSS color change)
Signed-off-by: Michael Lee <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: mac80211: fix min center freq offset tracing
Johannes Berg [Thu, 4 May 2023 13:45:01 +0000 (16:45 +0300)]
wifi: mac80211: fix min center freq offset tracing

We need to set the correct trace variable, otherwise we're
overwriting something else instead and the right one that
we print later is not initialized.

Fixes: b6011960f392 ("mac80211: handle channel frequency offset")
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: iwlwifi: mvm: rfi: disable RFI feature
Gregory Greenman [Sun, 30 Apr 2023 17:18:30 +0000 (20:18 +0300)]
wifi: iwlwifi: mvm: rfi: disable RFI feature

This feature depends on a platform bugfix. Until we have a
mechanism that can verify a platform has the required bugfix,
disable RFI.

Fixes: ef3ed33dfc8f ("wifi: iwlwifi: bump FW API to 77 for AX devices")
Reported-by: Jeff Chua <[email protected]>
Link: https://lore.kernel.org/linux-wireless/CAAJw_ZvZdFpw9W2Hisc9c2BAFbYAnQuaFFaFG6N7qPUP2fOL_w@mail.gmail.com/
Signed-off-by: Gregory Greenman <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: mac80211: Fix puncturing bitmap handling in __ieee80211_csa_finalize()
Christophe JAILLET [Mon, 24 Apr 2023 17:42:04 +0000 (19:42 +0200)]
wifi: mac80211: Fix puncturing bitmap handling in __ieee80211_csa_finalize()

'changed' can be OR'ed with BSS_CHANGED_EHT_PUNCTURING which is larger than
an u32.
So, turn 'changed' into an u64 and update ieee80211_set_after_csa_beacon()
accordingly.

In the commit in Fixes, only ieee80211_start_ap() was updated.

Fixes: 2cc25e4b2a04 ("wifi: mac80211: configure puncturing bitmap")
Signed-off-by: Christophe JAILLET <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Link: https://lore.kernel.org/r/e84a3f80fe536787f7a2c7180507efc36cd14f95.1682358088.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: mac80211: fortify the spinlock against deadlock by interrupt
Mirsad Goran Todorovac [Tue, 25 Apr 2023 16:40:08 +0000 (18:40 +0200)]
wifi: mac80211: fortify the spinlock against deadlock by interrupt

In the function ieee80211_tx_dequeue() there is a particular locking
sequence:

begin:
spin_lock(&local->queue_stop_reason_lock);
q_stopped = local->queue_stop_reasons[q];
spin_unlock(&local->queue_stop_reason_lock);

However small the chance (increased by ftracetest), an asynchronous
interrupt can occur in between of spin_lock() and spin_unlock(),
and the interrupt routine will attempt to lock the same
&local->queue_stop_reason_lock again.

This will cause a costly reset of the CPU and the wifi device or an
altogether hang in the single CPU and single core scenario.

The only remaining spin_lock(&local->queue_stop_reason_lock) that
did not disable interrupts was patched, which should prevent any
deadlocks on the same CPU/core and the same wifi device.

This is the probable trace of the deadlock:

kernel: ================================
kernel: WARNING: inconsistent lock state
kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G        W
kernel: --------------------------------
kernel: inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes:
kernel: ffff9d6190779478 (&local->queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40
kernel: {IN-SOFTIRQ-W} state was registered at:
kernel:   lock_acquire+0xc7/0x2d0
kernel:   _raw_spin_lock+0x36/0x50
kernel:   ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
kernel:   iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
kernel:   iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm]
kernel:   ieee80211_queue_skb+0x450/0x730 [mac80211]
kernel:   __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211]
kernel:   __ieee80211_subif_start_xmit+0x217/0x530 [mac80211]
kernel:   ieee80211_subif_start_xmit+0x60/0x580 [mac80211]
kernel:   dev_hard_start_xmit+0xb5/0x260
kernel:   __dev_queue_xmit+0xdbe/0x1200
kernel:   neigh_resolve_output+0x166/0x260
kernel:   ip_finish_output2+0x216/0xb80
kernel:   __ip_finish_output+0x2a4/0x4d0
kernel:   ip_finish_output+0x2d/0xd0
kernel:   ip_output+0x82/0x2b0
kernel:   ip_local_out+0xec/0x110
kernel:   igmpv3_sendpack+0x5c/0x90
kernel:   igmp_ifc_timer_expire+0x26e/0x4e0
kernel:   call_timer_fn+0xa5/0x230
kernel:   run_timer_softirq+0x27f/0x550
kernel:   __do_softirq+0xb4/0x3a4
kernel:   irq_exit_rcu+0x9b/0xc0
kernel:   sysvec_apic_timer_interrupt+0x80/0xa0
kernel:   asm_sysvec_apic_timer_interrupt+0x1f/0x30
kernel:   _raw_spin_unlock_irqrestore+0x3f/0x70
kernel:   free_to_partial_list+0x3d6/0x590
kernel:   __slab_free+0x1b7/0x310
kernel:   kmem_cache_free+0x52d/0x550
kernel:   putname+0x5d/0x70
kernel:   do_sys_openat2+0x1d7/0x310
kernel:   do_sys_open+0x51/0x80
kernel:   __x64_sys_openat+0x24/0x30
kernel:   do_syscall_64+0x5c/0x90
kernel:   entry_SYSCALL_64_after_hwframe+0x72/0xdc
kernel: irq event stamp: 5120729
kernel: hardirqs last  enabled at (5120729): [<ffffffff9d149936>] trace_graph_return+0xd6/0x120
kernel: hardirqs last disabled at (5120728): [<ffffffff9d149950>] trace_graph_return+0xf0/0x120
kernel: softirqs last  enabled at (5069900): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel: softirqs last disabled at (5067555): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel:
        other info that might help us debug this:
kernel:  Possible unsafe locking scenario:
kernel:        CPU0
kernel:        ----
kernel:   lock(&local->queue_stop_reason_lock);
kernel:   <Interrupt>
kernel:     lock(&local->queue_stop_reason_lock);
kernel:
         *** DEADLOCK ***
kernel: 8 locks held by kworker/5:0/25656:
kernel:  #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530
kernel:  #1: ffffb1ef4637fe68 ((work_completion)(&local->restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530
kernel:  #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel:  #3: ffff9d6190778728 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel:  #4: ffff9d619077b480 (&mvm->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel:  #5: ffff9d61907bacd8 (&trans_pcie->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel:  #6: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_queue_state_change+0x59/0x3a0 [iwlmvm]
kernel:  #7: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
kernel:
        stack backtrace:
kernel: CPU: 5 PID: 25656 Comm: kworker/5:0 Tainted: G        W          6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4
kernel: Hardware name: LENOVO 82H8/LNVNB161216, BIOS GGCN51WW 11/16/2022
kernel: Workqueue: events_freezable ieee80211_restart_work [mac80211]
kernel: Call Trace:
kernel:  <TASK>
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  dump_stack_lvl+0x5f/0xa0
kernel:  dump_stack+0x14/0x20
kernel:  print_usage_bug.part.46+0x208/0x2a0
kernel:  mark_lock.part.47+0x605/0x630
kernel:  ? sched_clock+0xd/0x20
kernel:  ? trace_clock_local+0x14/0x30
kernel:  ? __rb_reserve_next+0x5f/0x490
kernel:  ? _raw_spin_lock+0x1b/0x50
kernel:  __lock_acquire+0x464/0x1990
kernel:  ? mark_held_locks+0x4e/0x80
kernel:  lock_acquire+0xc7/0x2d0
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  ? ftrace_return_to_handler+0x8b/0x100
kernel:  ? preempt_count_add+0x4/0x70
kernel:  _raw_spin_lock+0x36/0x50
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
kernel:  ? prepare_ftrace_return+0xc5/0x190
kernel:  ? ftrace_graph_func+0x16/0x20
kernel:  ? 0xffffffffc02ab0b1
kernel:  ? lock_acquire+0xc7/0x2d0
kernel:  ? iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
kernel:  ? ieee80211_tx_dequeue+0x9/0x1330 [mac80211]
kernel:  ? __rcu_read_lock+0x4/0x40
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  iwl_mvm_queue_state_change+0x311/0x3a0 [iwlmvm]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  iwl_mvm_wake_sw_queue+0x17/0x20 [iwlmvm]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  iwl_txq_gen2_unmap+0x1c9/0x1f0 [iwlwifi]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  iwl_txq_gen2_free+0x55/0x130 [iwlwifi]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  iwl_txq_gen2_tx_free+0x63/0x80 [iwlwifi]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  _iwl_trans_pcie_gen2_stop_device+0x3f3/0x5b0 [iwlwifi]
kernel:  ? _iwl_trans_pcie_gen2_stop_device+0x9/0x5b0 [iwlwifi]
kernel:  ? mutex_lock_nested+0x4/0x30
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  iwl_trans_pcie_gen2_stop_device+0x5f/0x90 [iwlwifi]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  iwl_mvm_stop_device+0x78/0xd0 [iwlmvm]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  __iwl_mvm_mac_start+0x114/0x210 [iwlmvm]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  iwl_mvm_mac_start+0x76/0x150 [iwlmvm]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  drv_start+0x79/0x180 [mac80211]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  ieee80211_reconfig+0x1523/0x1ce0 [mac80211]
kernel:  ? synchronize_net+0x4/0x50
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  ieee80211_restart_work+0x108/0x170 [mac80211]
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  process_one_work+0x250/0x530
kernel:  ? ftrace_regs_caller_end+0x66/0x66
kernel:  worker_thread+0x48/0x3a0
kernel:  ? __pfx_worker_thread+0x10/0x10
kernel:  kthread+0x10f/0x140
kernel:  ? __pfx_kthread+0x10/0x10
kernel:  ret_from_fork+0x29/0x50
kernel:  </TASK>

Fixes: 4444bc2116ae ("wifi: mac80211: Proper mark iTXQs for resumption")
Link: https://lore.kernel.org/all/[email protected]/
Reported-by: Mirsad Goran Todorovac <[email protected]>
Cc: Gregory Greenman <[email protected]>
Cc: Johannes Berg <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/
Cc: David S. Miller <[email protected]>
Cc: Eric Dumazet <[email protected]>
Cc: Jakub Kicinski <[email protected]>
Cc: Paolo Abeni <[email protected]>
Cc: Leon Romanovsky <[email protected]>
Cc: Alexander Wetzel <[email protected]>
Signed-off-by: Mirsad Goran Todorovac <[email protected]>
Reviewed-by: Leon Romanovsky <[email protected]>
Reviewed-by: tag, or it goes automatically?
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Johannes Berg <[email protected]>
23 months agowifi: cfg80211: Drop entries with invalid BSSIDs in RNR
Ilan Peer [Mon, 24 Apr 2023 07:32:24 +0000 (10:32 +0300)]
wifi: cfg80211: Drop entries with invalid BSSIDs in RNR

Ignore AP information for entries that include an invalid
BSSID in the TBTT information field, e.g., all zeros BSSIDs.

Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning")
Signed-off-by: Ilan Peer <[email protected]>
Signed-off-by: Gregory Greenman <[email protected]>
Link: https://lore.kernel.org/r/20230424103224.5e65d04d1448.Ic10c8577ae4a85272c407106c9d0a2ecb5372743@changeid
Signed-off-by: Johannes Berg <[email protected]>
23 months agoiavf: send VLAN offloading caps once after VFR
Ahmed Zaki [Mon, 17 Apr 2023 18:09:39 +0000 (12:09 -0600)]
iavf: send VLAN offloading caps once after VFR

When the user disables rxvlan offloading and then changes the number of
channels, all VLAN ports are unable to receive traffic.

Changing the number of channels triggers a VFR reset. During re-init, when
VIRTCHNL_OP_GET_OFFLOAD_VLAN_V2_CAPS is received, we do:
1 - set the IAVF_FLAG_SETUP_NETDEV_FEATURES flag
2 - call
    iavf_set_vlan_offload_features(adapter, 0, netdev->features);

The second step sends to the PF the __default__ features, in this case
aq_required |= IAVF_FLAG_AQ_ENABLE_CTAG_VLAN_STRIPPING

While the first step forces the watchdog task to call
netdev_update_features() ->  iavf_set_features() ->
iavf_set_vlan_offload_features(adapter, netdev->features, features).
Since the user disabled the "rxvlan", this sets:
aq_required |= IAVF_FLAG_AQ_DISABLE_CTAG_VLAN_STRIPPING

When we start processing the AQ commands, both flags are enabled. Since we
process DISABLE_XTAG first then ENABLE_XTAG, this results in the PF
enabling the rxvlan offload. This breaks all communications on the VLAN
net devices.

Fix by removing the call to iavf_set_vlan_offload_features() (second
step). Calling netdev_update_features() from watchdog task is enough for
both init and reset paths.

Fixes: 7598f4b40bd6 ("iavf: Move netdev_update_features() into watchdog task")
Signed-off-by: Ahmed Zaki <[email protected]>
Tested-by: Rafal Romanowski <[email protected]>
Reviewed-by: Leon Romanovsky <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: Fix ice VF reset during iavf initialization
Dawid Wesierski [Tue, 18 Apr 2023 09:52:55 +0000 (11:52 +0200)]
ice: Fix ice VF reset during iavf initialization

Fix the current implementation that causes ice_trigger_vf_reset()
to start resetting the VF even when the VF-NIC is still initializing.

When we reset NIC with ice driver it can interfere with
iavf-vf initialization e.g. during consecutive resets induced by ice

iavf                ice
  |                  |
  |<-----------------|
  |            ice resets vf
 iavf                |
 reset               |
 start               |
  |<-----------------|
  |             ice resets vf
  |             causing iavf
  |             initialization
  |             error
  |                  |
 iavf
 reset
 end

This leads to a series of -53 errors
(failed to init adminq) from the IAVF.

Change the state of the vf_state field to be not active when the IAVF
is still initializing. Make sure to wait until receiving the message on
the message box to ensure that the vf is ready and initializded.

In simple terms we use the ACTIVE flag to make sure that the ice
driver knows if the iavf is ready for another reset

  iavf                  ice
    |                    |
    |                    |
    |<------------- ice resets vf
  iavf           vf_state != ACTIVE
  reset                  |
  start                  |
    |                    |
    |                    |
  iavf                   |
  reset-------> vf_state == ACTIVE
  end              ice resets vf
    |                    |
    |                    |

Fixes: c54d209c78b8 ("ice: Wait for VF to be reset/ready before configuration")
Signed-off-by: Dawid Wesierski <[email protected]>
Signed-off-by: Kamil Maziarz <[email protected]>
Acked-by: Jacob Keller <[email protected]>
Tested-by: Rafal Romanowski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: Fix stats after PF reset
Ahmed Zaki [Mon, 17 Apr 2023 23:44:45 +0000 (17:44 -0600)]
ice: Fix stats after PF reset

After a core PF reset, the VFs were showing wrong Rx/Tx stats. This is a
regression in commit 6624e780a577 ("ice: split ice_vsi_setup into smaller
functions") caused by missing to set "stat_offsets_loaded = false" in the
ice_vsi_rebuild() path.

Fixes: 6624e780a577 ("ice: split ice_vsi_setup into smaller functions")
Signed-off-by: Ahmed Zaki <[email protected]>
Reviewed-by: Alexander Lobakin <[email protected]>
Tested-by: Rafal Romanowski <[email protected]>
Reviewed-by: Leon Romanovsky <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: add dynamic interrupt allocation
Piotr Raczynski [Mon, 15 May 2023 19:03:19 +0000 (21:03 +0200)]
ice: add dynamic interrupt allocation

Currently driver can only allocate interrupt vectors during init phase by
calling pci_alloc_irq_vectors. Change that and make use of new
pci_msix_alloc_irq_at/pci_msix_free_irq API and enable to allocate and free
more interrupts after MSIX has been enabled. Since not all platforms
supports dynamic allocation, check it with pci_msix_can_alloc_dyn.

Extend the tracker to keep track how many interrupts are allocated
initially so when all such vectors are already used, additional interrupts
are automatically allocated dynamically. Remember each interrupt allocation
method to then free appropriately. Since some features may require
interrupts allocated dynamically add appropriate VSI flag and take it into
account when allocating new interrupt.

Reviewed-by: Michal Swiatkowski <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
Signed-off-by: Piotr Raczynski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: track interrupt vectors with xarray
Piotr Raczynski [Mon, 15 May 2023 19:03:18 +0000 (21:03 +0200)]
ice: track interrupt vectors with xarray

Replace custom interrupt tracker with generic xarray data structure.
Remove all code responsible for searching for a new entry with xa_alloc,
which always tries to allocate at the lowes possible index. As a result
driver is always using a contiguous region of the MSIX vector table.

New tracker keeps ice_irq_entry entries in xarray as opaque for the rest
of the driver hiding the entry details from the caller.

Reviewed-by: Jacob Keller <[email protected]>
Reviewed-by: Michal Swiatkowski <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
Signed-off-by: Piotr Raczynski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: add individual interrupt allocation
Piotr Raczynski [Mon, 15 May 2023 19:03:17 +0000 (21:03 +0200)]
ice: add individual interrupt allocation

Currently interrupt allocations, depending on a feature are distributed
in batches. Also, after allocation there is a series of operations that
distributes per irq settings through that batch of interrupts.

Although driver does not yet support dynamic interrupt allocation, keep
allocated interrupts in a pool and add allocation abstraction logic to
make code more flexible. Keep per interrupt information in the
ice_q_vector structure, which yields ice_vsi::base_vector redundant.
Also, as a result there are a few functions that can be removed.

Reviewed-by: Jacob Keller <[email protected]>
Reviewed-by: Michal Swiatkowski <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
Signed-off-by: Piotr Raczynski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: remove redundant SRIOV code
Piotr Raczynski [Mon, 15 May 2023 19:03:16 +0000 (21:03 +0200)]
ice: remove redundant SRIOV code

Remove redundant code from ice_get_max_valid_res_idx that has no effect.
ice_pf::irq_tracker is initialized during driver probe, there is no reason
to check it again. Also it is not possible for pf::sriov_base_vector to be
lower than the tracker length, remove WARN_ON that will never happen.

Get rid of ice_get_max_valid_res_idx helper function completely since it
can never return negative value.

Reviewed-by: Jacob Keller <[email protected]>
Reviewed-by: Michal Swiatkowski <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Rafal Romanowski <[email protected]>
Signed-off-by: Piotr Raczynski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: refactor VF control VSI interrupt handling
Piotr Raczynski [Mon, 15 May 2023 19:03:15 +0000 (21:03 +0200)]
ice: refactor VF control VSI interrupt handling

All VF control VSIs share the same interrupt vector. Currently, a helper
function dedicated for that directly sets ice_vsi::base_vector.

Use helper that returns pointer to first found VF control VSI instead.

Reviewed-by: Jacob Keller <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Rafal Romanowski <[email protected]>
Signed-off-by: Piotr Raczynski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: use preferred MSIX allocation api
Piotr Raczynski [Mon, 15 May 2023 19:03:14 +0000 (21:03 +0200)]
ice: use preferred MSIX allocation api

Move away from using pci_enable_msix_range/pci_disable_msix and use
pci_alloc_irq_vectors/pci_free_irq_vectors instead.

As a result stop tracking msix_entries since with newer API entries are
handled by MSIX core. However, due to current design of communication
with RDMA driver which accesses ice_pf::msix_entries directly, keep
using the array just for RDMA driver use.

Reviewed-by: Michal Swiatkowski <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
Signed-off-by: Piotr Raczynski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: use pci_irq_vector helper function
Piotr Raczynski [Mon, 15 May 2023 19:03:13 +0000 (21:03 +0200)]
ice: use pci_irq_vector helper function

Currently, driver gets interrupt number directly from ice_pf::msix_entries
array. Use helper function dedicated to do just that.

While at it use a variable to store interrupt number in
ice_free_irq_msix_misc instead of calling the helper function twice.

Reviewed-by: Michal Swiatkowski <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
Signed-off-by: Piotr Raczynski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoice: move interrupt related code to separate file
Piotr Raczynski [Mon, 15 May 2023 19:03:12 +0000 (21:03 +0200)]
ice: move interrupt related code to separate file

Keep interrupt handling code in a dedicated file. This helps keep driver
structured better and prepares for more functionality added to this file.

Reviewed-by: Jacob Keller <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
Signed-off-by: Piotr Raczynski <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
23 months agoMerge branch 'spdx-conversion-for-bonding-8390-and-i825xx-drivers'
Paolo Abeni [Tue, 16 May 2023 13:39:09 +0000 (15:39 +0200)]
Merge branch 'spdx-conversion-for-bonding-8390-and-i825xx-drivers'

Bagas Sanjaya says:

====================
SPDX conversion for bonding, 8390, and i825xx drivers

This series is SPDX conversion for bonding, 8390, and i825xx driver
subsystems. It is splitted from v2 of my SPDX conversion series in
response to Didi's GPL full name fixes [1] to make it easily
digestible.

The conversion in this series is divided by each subsystem and by
license type.

[1]: https://lore.kernel.org/linux-spdx/20230512100620[email protected]/
====================

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
23 months agonet: ethernet: i825xx: sun3_8256: Add SPDX license identifier
Bagas Sanjaya [Mon, 15 May 2023 06:07:15 +0000 (13:07 +0700)]
net: ethernet: i825xx: sun3_8256: Add SPDX license identifier

The boilerplate reads that sun3_8256 driver is an extension to Linux
kernel core, hence add SPDX license identifier for GPL 2.0.

Cc: Greg Kroah-Hartman <[email protected]>
Cc: Michael Hipp <[email protected]>
Cc: Sam Creasey <[email protected]>
Signed-off-by: Bagas Sanjaya <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
23 months agonet: ethernet: i825xx: Replace unversioned GPL (GPL 1.0) notice with SPDX identifier
Bagas Sanjaya [Mon, 15 May 2023 06:07:14 +0000 (13:07 +0700)]
net: ethernet: i825xx: Replace unversioned GPL (GPL 1.0) notice with SPDX identifier

Replace unversioned GPL boilerplate notice with corresponding SPDX
license identifier, which is GPL 1.0+.

Cc: Donald Becker <[email protected]>
Cc: Richard Hirst <[email protected]>
Cc: Sam Creasey <[email protected]>
Signed-off-by: Bagas Sanjaya <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
23 months agonet: ethernet: 8390: Replace GPL 2.0 boilerplate with SPDX identifier
Bagas Sanjaya [Mon, 15 May 2023 06:07:13 +0000 (13:07 +0700)]
net: ethernet: 8390: Replace GPL 2.0 boilerplate with SPDX identifier

The boilerplate refers to COPYING in the top-level directory of kernel
tree. Replace it with corresponding SPDX license identifier.

Cc: Donald Becker <[email protected]>
Cc: Peter De Schrijver <[email protected]>
Cc: Topi Kanerva <[email protected]>
Cc: Alain Malek <[email protected]>
Cc: Bruce Abbott <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Richard Fontana <[email protected]>
Acked-by: Greg Ungerer <[email protected]>
Signed-off-by: Bagas Sanjaya <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
23 months agonet: ethernet: 8390: Convert unversioned GPL notice to SPDX license identifier
Bagas Sanjaya [Mon, 15 May 2023 06:07:12 +0000 (13:07 +0700)]
net: ethernet: 8390: Convert unversioned GPL notice to SPDX license identifier

Replace boilerplate notice for unversioned GPL to SPDX tag for GPL 1.0+.
For ne2k-pci.c, only add SPDX tag and keep the boilerplate instead,
since the boilerplate notes that it must be preserved.

Cc: David A. Hinds <[email protected]>
Cc: Donald Becker <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Richard Fontana <[email protected]>
Signed-off-by: Bagas Sanjaya <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
23 months agonet: bonding: Add SPDX identifier to remaining files
Bagas Sanjaya [Mon, 15 May 2023 06:07:11 +0000 (13:07 +0700)]
net: bonding: Add SPDX identifier to remaining files

Previous batches of SPDX conversion missed bond_main.c and bonding_priv.h
because these files doesn't mention intended GPL version. Add SPDX identifier
to these files, assuming GPL 1.0+.

Cc: Thomas Davis <[email protected]>
Cc: Christophe JAILLET <[email protected]>
Cc: Stephen Hemminger <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Bagas Sanjaya <[email protected]>
Signed-off-by: Paolo Abeni <[email protected]>
23 months agonet: skbuff: update comment about pfmemalloc propagating
Yunsheng Lin [Mon, 15 May 2023 05:01:07 +0000 (13:01 +0800)]
net: skbuff: update comment about pfmemalloc propagating

__skb_fill_page_desc_noacc() is not doing any pfmemalloc
propagating, and yet it has a comment about that, commit
84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc")
may have accidentally moved it to __skb_fill_page_desc_noacc(),
so move it back to __skb_fill_page_desc() which is supposed
to be doing pfmemalloc propagating.

Signed-off-by: Yunsheng Lin <[email protected]>
CC: Pavel Begunkov <[email protected]>
Reviewed-by: Pavel Begunkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
23 months agonet: bcmgenet: Restore phy_stop() depending upon suspend/close
Florian Fainelli [Mon, 15 May 2023 02:56:07 +0000 (19:56 -0700)]
net: bcmgenet: Restore phy_stop() depending upon suspend/close

Removing the phy_stop() from bcmgenet_netif_stop() ended up causing
warnings from the PHY library that phy_start() is called from the
RUNNING state since we are no longer stopping the PHY state machine
during bcmgenet_suspend().

Restore the call to phy_stop() but make it conditional on being called
from the close or suspend path.

Fixes: c96e731c93ff ("net: bcmgenet: connect and disconnect from the PHY state machine")
Fixes: 93e0401e0fc0 ("net: bcmgenet: Remove phy_stop() from bcmgenet_netif_stop()")
Signed-off-by: Florian Fainelli <[email protected]>
Reviewed-by: Pavan Chebbi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
23 months agotpm/tpm_tis: Disable interrupts for more Lenovo devices
Jerry Snitselaar [Thu, 11 May 2023 00:54:03 +0000 (17:54 -0700)]
tpm/tpm_tis: Disable interrupts for more Lenovo devices

The P360 Tiny suffers from an irq storm issue like the T490s, so add
an entry for it to tpm_tis_dmi_table, and force polling. There also
previously was a report from the previous attempt to enable interrupts
that involved a ThinkPad L490. So an entry is added for it as well.

Cc: [email protected]
Reported-by: Peter Zijlstra <[email protected]> # P360 Tiny
Closes: https://lore.kernel.org/linux-integrity/[email protected]/
Signed-off-by: Jerry Snitselaar <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
23 months agotpm: Prevent hwrng from activating during resume
Jarkko Sakkinen [Wed, 26 Apr 2023 17:29:28 +0000 (20:29 +0300)]
tpm: Prevent hwrng from activating during resume

Set TPM_CHIP_FLAG_SUSPENDED in tpm_pm_suspend() and reset in
tpm_pm_resume(). While the flag is set, tpm_hwrng() gives back zero
bytes. This prevents hwrng from racing during resume.

Cc: [email protected]
Fixes: 6e592a065d51 ("tpm: Move Linux RNG connection to hwrng")
Reviewed-by: Jerry Snitselaar <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
23 months agotpm_tis: Use tpm_chip_{start,stop} decoration inside tpm_tis_resume
Jarkko Sakkinen [Wed, 26 Apr 2023 17:29:27 +0000 (20:29 +0300)]
tpm_tis: Use tpm_chip_{start,stop} decoration inside tpm_tis_resume

Before sending a TPM command, CLKRUN protocol must be disabled. This is not
done in the case of tpm1_do_selftest() call site inside tpm_tis_resume().

Address this by decorating the calls with tpm_chip_{start,stop}, which
should be always used to arm and disarm the TPM chip for transmission.

Finally, move the call to the main TPM driver callback as the last step
because it should arm the chip by itself, if it needs that type of
functionality.

Cc: [email protected]
Reported-by: Jason A. Donenfeld <[email protected]>
Closes: https://lore.kernel.org/linux-integrity/CS68AWILHXS4.3M36M1EKZLUMS@suppilovahvero/
Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()")
Reviewed-by: Jerry Snitselaar <[email protected]>
Signed-off-by: Jarkko Sakkinen <[email protected]>
23 months agobpf: Fix memleak due to fentry attach failure
Yafang Shao [Mon, 15 May 2023 13:08:47 +0000 (13:08 +0000)]
bpf: Fix memleak due to fentry attach failure

If it fails to attach fentry, the allocated bpf trampoline image will be
left in the system. That can be verified by checking /proc/kallsyms.

This meamleak can be verified by a simple bpf program as follows:

  SEC("fentry/trap_init")
  int fentry_run()
  {
      return 0;
  }

It will fail to attach trap_init because this function is freed after
kernel init, and then we can find the trampoline image is left in the
system by checking /proc/kallsyms.

  $ tail /proc/kallsyms
  ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]
  ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]

  $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'"
  [2522] FUNC 'trap_init' type_id=119 linkage=static

  $ echo $((6442453466 & 0x7fffffff))
  2522

Note that there are two left bpf trampoline images, that is because the
libbpf will fallback to raw tracepoint if -EINVAL is returned.

Fixes: e21aa341785c ("bpf: Fix fexit trampoline.")
Signed-off-by: Yafang Shao <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Song Liu <[email protected]>
Cc: Jiri Olsa <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
23 months agoMerge patch series "can: Convert to platform remove callback returning void"
Marc Kleine-Budde [Mon, 15 May 2023 20:54:22 +0000 (22:54 +0200)]
Merge patch series "can: Convert to platform remove callback returning void"

Uwe Kleine-König <[email protected]> says:

this series converts the drivers below drivers/net/can to the
.remove_new() callback of struct platform_driver(). The motivation is to
make the remove callback less prone for errors and wrong assumptions.
See commit 5c5a7680e67b ("platform: Provide a remove callback that
returns no value") for a more detailed rationale.

All drivers already returned zero unconditionally in their
.remove() callback, so converting them to .remove_new() is trivial.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: xilinx: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:25 +0000 (23:27 +0200)]
can: xilinx: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: ti_hecc: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:24 +0000 (23:27 +0200)]
can: ti_hecc: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: sun4i_can: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:23 +0000 (23:27 +0200)]
can: sun4i_can: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Gerhard Bertelsmann <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: softing: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:22 +0000 (23:27 +0200)]
can: softing: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: sja1000_platform: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:21 +0000 (23:27 +0200)]
can: sja1000_platform: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: sja1000_isa: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:20 +0000 (23:27 +0200)]
can: sja1000_isa: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: rcar: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:19 +0000 (23:27 +0200)]
can: rcar: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert these drivers from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: mscan: mpc5xxx_can: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:18 +0000 (23:27 +0200)]
can: mscan: mpc5xxx_can: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: m_can: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:17 +0000 (23:27 +0200)]
can: m_can: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: janz-ican3: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:16 +0000 (23:27 +0200)]
can: janz-ican3: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: ifi_canfd: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:15 +0000 (23:27 +0200)]
can: ifi_canfd: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: grcan: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:14 +0000 (23:27 +0200)]
can: grcan: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: flexcan: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:13 +0000 (23:27 +0200)]
can: flexcan: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: ctucanfd: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:12 +0000 (23:27 +0200)]
can: ctucanfd: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Pavel Pisa <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: length: make header self contained
Marc Kleine-Budde [Sun, 23 Apr 2023 11:06:39 +0000 (13:06 +0200)]
can: length: make header self contained

Include the headers that "can/length.h" depends on.

Fixes: bdd2e413192d ("can: dev: move length related code into seperate file")
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: cc770_platform: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:11 +0000 (23:27 +0200)]
can: cc770_platform: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: bxcan: Remove unnecessary print function dev_err()
Jiapeng Chong [Sat, 6 May 2023 08:07:25 +0000 (16:07 +0800)]
can: bxcan: Remove unnecessary print function dev_err()

The print function dev_err() is redundant because
platform_get_irq_byname() already prints an error.

./drivers/net/can/bxcan.c:970:2-9: line 970 is redundant because platform_get_irq() already prints an error.
./drivers/net/can/bxcan.c:964:2-9: line 964 is redundant because platform_get_irq() already prints an error.
./drivers/net/can/bxcan.c:958:2-9: line 958 is redundant because platform_get_irq() already prints an error.

Reported-by: Abaci Robot <[email protected]>
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4878
Signed-off-by: Jiapeng Chong <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: cc770_isa: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:10 +0000 (23:27 +0200)]
can: cc770_isa: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: usb: f81604: add Fintek F81604 support
Ji-Ze Hong [Tue, 9 May 2023 07:38:21 +0000 (15:38 +0800)]
can: usb: f81604: add Fintek F81604 support

This patch adds support for Fintek USB to 2CAN controller.

Changelog:
v7: https://lore.kernel.org/all/20230509073821[email protected]
  1. Fix consistency of coding style for "break" in f81604_register_urbs().
  2. Remove goto statement in f81604_open().

v6: https://lore.kernel.org/all/20230505022317[email protected]
  1. Remove non-used define and change constant mask to GENMASK().
  2. Move some variables declaration from function start to block start.
  3. Move some variables initization into declaration.
  4. Change variable "id" in f81604_start_xmit() only for CAN ID usage.

v5: https://lore.kernel.org/all/20230420024403[email protected]
  1. Change all u8 *buff to struct f81604_int_data/f81604_can_frame.
  2. Change all netdev->dev_id to netdev->dev_port.
  3. Remove over design for f81604_process_rx_packet(). This device only
     report a frame at once, so the f81604_process_rx_packet() are reduced
     to process 1 frame.

v4: https://lore.kernel.org/all/20230413084253[email protected]
  1. Remove f81604_prepare_urbs/f81604_remove_urbs() and alloc URB/buffer
     dynamically in f81604_register_urbs(), using "urbs_anchor" for manage
     all rx/int URBs.
  2. Add F81604 to MAINTAINERS list.
  3. Change handle_clear_reg_work/handle_clear_overrun_work to single
     clear_reg_work and using bitwise "clear_flags" to record it.
  4. Move __f81604_set_termination in front of f81604_probe() to avoid
     rarely racing condition.
  5. Add __aligned to struct f81604_int_data / f81604_sff / f81604_eff.
  6. Add aligned operations in f81604_start_xmit/f81604_process_rx_packet().
  7. Change lots of CANBUS functions first parameter from struct usb_device*
     to struct f81604_port_priv *priv. But remain f81604_write / f81604_read
     / f81604_update_bits() as struct usb_device* for
     __f81604_set_termination() in probe() stage.
  8. Simplify f81604_read_int_callback() and separate into
     f81604_handle_tx / f81604_handle_can_bus_errors() functions.

v3: https://lore.kernel.org/all/20230327051048[email protected]
  1. Change CAN clock to using MEGA units.
  2. Remove USB set/get retry, only remain SJA1000 reset/operation retry.
  3. Fix all numberic constant to define.
  4. Add terminator control. (only 0 & 120 ohm)
  5. Using struct data to represent INT/TX/RX endpoints data instead byte
     arrays.
  6. Error message reports changed from %d to %pe for mnemotechnic values.
  7. Some bit operations are changed to FIELD_PREP().
  8. Separate TX functions from f81604_read_int_callback().
  9. cf->can_id |= CAN_ERR_CNT in f81604_read_int_callback to report valid
     TX/RX error counts.
  10. Move f81604_prepare_urbs/f81604_remove_urbs() from CAN open/close() to
      USB probe/disconnect().
  11. coding style refactoring.

v2: https://lore.kernel.org/all/20230321081152[email protected]
  1. coding style refactoring.
  2. some const number are defined to describe itself.
  3. fix wrong usage for can_get_echo_skb() in f81604_write_bulk_callback().

v1: https://lore.kernel.org/all/20230317093352[email protected]

Signed-off-by: Ji-Ze Hong (Peter Hong) <[email protected]>
Reviewed-by: Vincent Mailhol <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
[mkl: add changelog, fix printf format]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: c_can: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:09 +0000 (23:27 +0200)]
can: c_can: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: bxcan: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:08 +0000 (23:27 +0200)]
can: bxcan: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: at91_can: Convert to platform remove callback returning void
Uwe Kleine-König [Fri, 12 May 2023 21:27:07 +0000 (23:27 +0200)]
can: at91_can: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart from
emitting a warning) and this typically results in resource leaks. To improve
here there is a quest to make the remove callback return void. In the first
step of this quest all drivers are converted to .remove_new() which already
returns void. Eventually after all drivers are converted, .remove_new() is
renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Claudiu Beznea <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agoMerge patch series "can: bxcan: add support for single peripheral configuration"
Marc Kleine-Budde [Mon, 15 May 2023 20:26:39 +0000 (22:26 +0200)]
Merge patch series "can: bxcan: add support for single peripheral configuration"

Dario Binacchi <[email protected]> says:

The series adds support for managing bxCAN controllers in single peripheral
configuration.
Unlike stm32f4 SOCs, where bxCAN controllers are only in dual peripheral
configuration, stm32f7 SOCs contain three CAN peripherals, CAN1 and CAN2
in dual peripheral configuration and CAN3 in single peripheral
configuration:
- Dual CAN peripheral configuration:
 * CAN1: Primary bxCAN for managing the communication between a secondary
   bxCAN and the 512-byte SRAM memory.
 * CAN2: Secondary bxCAN with no direct access to the SRAM memory.
   This means that the two bxCAN cells share the 512-byte SRAM memory and
   CAN2 can't be used without enabling CAN1.
- Single CAN peripheral configuration:
 * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and
   512-byte SRAM memory.

The driver has been tested on the stm32f769i-discovery board with a
kernel version 5.19.0-rc2 in loopback + silent mode:

| ip link set can[0-2] type can bitrate 125000 loopback on listen-only on
| ip link set up can[0-2]
| candump can[0-2] -L &
| cansend can[0-2] 300#AC.AB.AD.AE.75.49.AD.D1

Changes in v2:
- s/fiter/filter/ in the commit message
- Replace struct bxcan_mb::primary with struct bxcan_mb::cfg.
- Move after the patch "can: bxcan: add support for single peripheral configuration".
- Add node gcan3.
- Rename gcan as gcan1.
- Add property "st,can-secondary" to can2 node.
- Drop patch "dt-bindings: mfd: stm32f7: add binding definition for CAN3"
  because it has been accepted.
- Add patch "ARM: dts: stm32f429: put can2 in secondary mode".
- Add patch "dt-bindings: net: can: add "st,can-secondary" property".

v1: https://lore.kernel.org/all/20230423172528.1398158[email protected]

Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agoARM: dts: stm32: add CAN support on stm32f746
Dario Binacchi [Thu, 27 Apr 2023 20:45:40 +0000 (22:45 +0200)]
ARM: dts: stm32: add CAN support on stm32f746

Add support for bxcan (Basic eXtended CAN controller) to STM32F746. The
chip contains three CAN peripherals, CAN1 and CAN2 in dual peripheral
configuration and CAN3 in single peripheral configuration:
- Dual CAN peripheral configuration:
  * CAN1: Primary bxCAN for managing the communication between a secondary
    bxCAN and the 512-byte SRAM memory.
  * CAN2: Secondary bxCAN with no direct access to the SRAM memory.
  This means that the two bxCAN cells share the 512-byte SRAM memory and
  CAN2 can't be used without enabling CAN1.
- Single CAN peripheral configuration:
  * CAN3: Primary bxCAN with dedicated Memory Access Controller unit and
    512-byte SRAM memory.

 -------------------------------------------------------------------------
| features | CAN1              | CAN2               | CAN 3               |
 -------------------------------------------------------------------------
| SRAM     | 512-byte shared between CAN1 & CAN2    | 512-byte            |
 -------------------------------------------------------------------------
| Filters  | 26 filters shared between CAN1 & CAN2  | 14 filters          |
 -------------------------------------------------------------------------

Signed-off-by: Dario Binacchi <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: bxcan: add support for single peripheral configuration
Dario Binacchi [Thu, 27 Apr 2023 20:45:39 +0000 (22:45 +0200)]
can: bxcan: add support for single peripheral configuration

Add support for bxCAN controller in single peripheral configuration:
- primary bxCAN
- dedicated Memory Access Controller unit
- 512-byte SRAM memory
- 14 filter banks

Signed-off-by: Dario Binacchi <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agoARM: dts: stm32: add pin map for CAN controller on stm32f7
Dario Binacchi [Thu, 27 Apr 2023 20:45:38 +0000 (22:45 +0200)]
ARM: dts: stm32: add pin map for CAN controller on stm32f7

Add pin configurations for using CAN controller on stm32f7.

Signed-off-by: Dario Binacchi <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agoARM: dts: stm32f429: put can2 in secondary mode
Dario Binacchi [Thu, 27 Apr 2023 20:45:37 +0000 (22:45 +0200)]
ARM: dts: stm32f429: put can2 in secondary mode

This is a preparation patch for the upcoming support to manage CAN
peripherals in single configuration.

The addition ensures backwards compatibility.

Signed-off-by: Dario Binacchi <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agodt-bindings: net: can: add "st,can-secondary" property
Dario Binacchi [Thu, 27 Apr 2023 20:45:36 +0000 (22:45 +0200)]
dt-bindings: net: can: add "st,can-secondary" property

On the stm32f7 Socs the can peripheral can be in single or dual
configuration. In the dual configuration, in turn, it can be in primary
or secondary mode. The addition of the 'st,can-secondary' property allows
you to specify this mode in the dual configuration.

CAN peripheral nodes in single configuration contain neither
"st,can-primary" nor "st,can-secondary".

Signed-off-by: Dario Binacchi <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: CAN_BXCAN should depend on ARCH_STM32
Geert Uytterhoeven [Tue, 4 Apr 2023 11:59:00 +0000 (13:59 +0200)]
can: CAN_BXCAN should depend on ARCH_STM32

The STMicroelectronics STM32 basic extended CAN Controller (bxCAN) is
only present on STM32 SoCs.  Hence drop the "|| OF" part from its
dependency rule, to prevent asking the user about this driver when
configuring a kernel without STM32 SoC support.

Fixes: f00647d8127be4d3 ("can: bxcan: add support for ST bxCAN controller")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Link: https://lore.kernel.org/all/40095112efd1b2214e4223109fd9f0c6d0158a2d.1680609318.git.geert+renesas@glider.be
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: dev: fix missing CAN XL support in can_put_echo_skb()
Oliver Hartkopp [Sat, 6 May 2023 18:45:15 +0000 (20:45 +0200)]
can: dev: fix missing CAN XL support in can_put_echo_skb()

can_put_echo_skb() checks for the enabled IFF_ECHO flag and the
correct ETH_P type of the given skbuff. When implementing the CAN XL
support the new check for ETH_P_CANXL has been forgotten.

Fixes: fb08cba12b52 ("can: canxl: update CAN infrastructure for CAN XL frames")
Signed-off-by: Oliver Hartkopp <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: j1939: recvmsg(): allow MSG_CMSG_COMPAT flag
Oliver Hartkopp [Thu, 6 Apr 2023 11:08:45 +0000 (13:08 +0200)]
can: j1939: recvmsg(): allow MSG_CMSG_COMPAT flag

The control message provided by J1939 support MSG_CMSG_COMPAT but
blocked recvmsg() syscalls that have set this flag, i.e. on 32bit user
space on 64 bit kernels.

Link: https://github.com/hartkopp/can-isotp/issues/59
Cc: Oleksij Rempel <[email protected]>
Suggested-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Tested-by: Oleksij Rempel <[email protected]>
Acked-by: Oleksij Rempel <[email protected]>
Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Link: https://lore.kernel.org/[email protected]
Cc: [email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agocan: isotp: recvmsg(): allow MSG_CMSG_COMPAT flag
Oliver Hartkopp [Thu, 6 Apr 2023 11:08:45 +0000 (13:08 +0200)]
can: isotp: recvmsg(): allow MSG_CMSG_COMPAT flag

The control message provided by isotp support MSG_CMSG_COMPAT but
blocked recvmsg() syscalls that have set this flag, i.e. on 32bit user
space on 64 bit kernels.

Link: https://github.com/hartkopp/can-isotp/issues/59
Cc: Oleksij Rempel <[email protected]>
Suggested-by: Marc Kleine-Budde <[email protected]>
Signed-off-by: Oliver Hartkopp <[email protected]>
Fixes: 42bf50a1795a ("can: isotp: support MSG_TRUNC flag when reading from socket")
Link: https://lore.kernel.org/[email protected]
Cc: [email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>
23 months agobpf: Remove bpf trampoline selector
Yafang Shao [Mon, 15 May 2023 13:08:48 +0000 (13:08 +0000)]
bpf: Remove bpf trampoline selector

After commit e21aa341785c ("bpf: Fix fexit trampoline."), the selector is only
used to indicate how many times the bpf trampoline image are updated and been
displayed in the trampoline ksym name. After the trampoline is freed, the
selector will start from 0 again. So the selector is a useless value to the
user. We can remove it.

If the user want to check whether the bpf trampoline image has been updated
or not, the user can compare the address. Each time the trampoline image is
updated, the address will change consequently. Jiri also pointed out another
issue that perf is still using the old name "bpf_trampoline_%lu", so this
change can fix the issue in perf.

Fixes: e21aa341785c ("bpf: Fix fexit trampoline.")
Signed-off-by: Yafang Shao <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Song Liu <[email protected]>
Cc: Jiri Olsa <[email protected]>
Link: https://lore.kernel.org/bpf/ZFvOOlrmHiY9AgXE@krava
Link: https://lore.kernel.org/bpf/[email protected]
23 months agobpf, arm64: Support struct arguments in the BPF trampoline
Florent Revest [Thu, 11 May 2023 14:05:07 +0000 (16:05 +0200)]
bpf, arm64: Support struct arguments in the BPF trampoline

This extends the BPF trampoline JIT to support attachment to functions
that take small structures (up to 128bit) as argument. This is trivially
achieved by saving/restoring a number of "argument registers" rather
than a number of arguments.

The AAPCS64 section 6.8.2 describes the parameter passing ABI.
"Composite types" (like C structs) below 16 bytes (as enforced by the
BPF verifier) are provided as part of the 8 argument registers as
explained in the section C.12.

Signed-off-by: Florent Revest <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Acked-by: Xu Kuohai <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
23 months agobpftool: JIT limited misreported as negative value on aarch64
Alan Maguire [Fri, 12 May 2023 11:31:34 +0000 (12:31 +0100)]
bpftool: JIT limited misreported as negative value on aarch64

On aarch64, "bpftool feature" reports an incorrect BPF JIT limit:

$ sudo /sbin/bpftool feature
Scanning system configuration...
bpf() syscall restricted to privileged users
JIT compiler is enabled
JIT compiler hardening is disabled
JIT compiler kallsyms exports are enabled for root
skipping kernel config, can't open file: No such file or directory
Global memory limit for JIT compiler for unprivileged users is -201326592 bytes

This is because /proc/sys/net/core/bpf_jit_limit reports

$ sudo cat /proc/sys/net/core/bpf_jit_limit
68169519595520

...and an int is assumed in read_procfs().  Change read_procfs()
to return a long to avoid negative value reporting.

Fixes: 7a4522bbef0c ("tools: bpftool: add probes for /proc/ eBPF parameters")
Reported-by: Nicky Veitch <[email protected]>
Signed-off-by: Alan Maguire <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Acked-by: Quentin Monnet <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
23 months agobpf: fix calculation of subseq_idx during precision backtracking
Andrii Nakryiko [Mon, 15 May 2023 18:07:10 +0000 (11:07 -0700)]
bpf: fix calculation of subseq_idx during precision backtracking

Subsequent instruction index (subseq_idx) is an index of an instruction
that was verified/executed by verifier after the currently processed
instruction. It is maintained during precision backtracking processing
and is used to detect various subprog calling conditions.

This patch fixes the bug with incorrectly resetting subseq_idx to -1
when going from child state to parent state during backtracking. If we
don't maintain correct subseq_idx we can misidentify subprog calls
leading to precision tracking bugs.

One such case was triggered by test_global_funcs/global_func9 test where
global subprog call happened to be the very last instruction in parent
state, leading to subseq_idx==-1, triggering WARN_ONCE:

  [   36.045754] verifier backtracking bug
  [   36.045764] WARNING: CPU: 13 PID: 2073 at kernel/bpf/verifier.c:3503 __mark_chain_precision+0xcc6/0xde0
  [   36.046819] Modules linked in: aesni_intel(E) crypto_simd(E) cryptd(E) kvm_intel(E) kvm(E) irqbypass(E) i2c_piix4(E) serio_raw(E) i2c_core(E) crc32c_intel)
  [   36.048040] CPU: 13 PID: 2073 Comm: test_progs Tainted: G        W  OE      6.3.0-07976-g4d585f48ee6b-dirty #972
  [   36.048783] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
  [   36.049648] RIP: 0010:__mark_chain_precision+0xcc6/0xde0
  [   36.050038] Code: 3d 82 c6 05 bb 35 32 02 01 e8 66 21 ec ff 0f 0b b8 f2 ff ff ff e9 30 f5 ff ff 48 c7 c7 f3 61 3d 82 4c 89 0c 24 e8 4a 21 ec ff <0f> 0b 4c0

With the fix precision tracking across multiple states works correctly now:

mark_precise: frame0: last_idx 45 first_idx 38 subseq_idx -1
mark_precise: frame0: regs=r8 stack= before 44: (61) r7 = *(u32 *)(r10 -4)
mark_precise: frame0: regs=r8 stack= before 43: (85) call pc+41
mark_precise: frame0: regs=r8 stack= before 42: (07) r1 += -48
mark_precise: frame0: regs=r8 stack= before 41: (bf) r1 = r10
mark_precise: frame0: regs=r8 stack= before 40: (63) *(u32 *)(r10 -48) = r1
mark_precise: frame0: regs=r8 stack= before 39: (b4) w1 = 0
mark_precise: frame0: regs=r8 stack= before 38: (85) call pc+38
mark_precise: frame0: parent state regs=r8 stack=:  R0_w=scalar() R1_w=map_value(off=4,ks=4,vs=8,imm=0) R6=1 R7_w=scalar() R8_r=P0 R10=fpm
mark_precise: frame0: last_idx 36 first_idx 28 subseq_idx 38
mark_precise: frame0: regs=r8 stack= before 36: (18) r1 = 0xffff888104f2ed14
mark_precise: frame0: regs=r8 stack= before 35: (85) call pc+33
mark_precise: frame0: regs=r8 stack= before 33: (18) r1 = 0xffff888104f2ed10
mark_precise: frame0: regs=r8 stack= before 32: (85) call pc+36
mark_precise: frame0: regs=r8 stack= before 31: (07) r1 += -4
mark_precise: frame0: regs=r8 stack= before 30: (bf) r1 = r10
mark_precise: frame0: regs=r8 stack= before 29: (63) *(u32 *)(r10 -4) = r7
mark_precise: frame0: regs=r8 stack= before 28: (4c) w7 |= w0
mark_precise: frame0: parent state regs=r8 stack=:  R0_rw=scalar() R6=1 R7_rw=scalar() R8_rw=P0 R10=fp0 fp-48_r=mmmmmmmm
mark_precise: frame0: last_idx 27 first_idx 16 subseq_idx 28
mark_precise: frame0: regs=r8 stack= before 27: (85) call pc+31
mark_precise: frame0: regs=r8 stack= before 26: (b7) r1 = 0
mark_precise: frame0: regs=r8 stack= before 25: (b7) r8 = 0

Note how subseq_idx starts out as -1, then is preserved as 38 and then 28 as we
go up the parent state chain.

Reported-by: Alexei Starovoitov <[email protected]>
Fixes: fde2a3882bd0 ("bpf: support precision propagation in the presence of subprogs")
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
23 months agowifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value
Yun Lu [Fri, 12 May 2023 01:20:55 +0000 (09:20 +0800)]
wifi: rtl8xxxu: fix authentication timeout due to incorrect RCR value

When using rtl8192cu with rtl8xxxu driver to connect wifi, there is a
probability of failure, which shows "authentication with ... timed out".
Through debugging, it was found that the RCR register has been inexplicably
modified to an incorrect value, resulting in the nic not being able to
receive authenticated frames.

To fix this problem, add regrcr in rtl8xxxu_priv struct, and store
the RCR value every time the register is written, and use it the next
time the register need to be modified.

Signed-off-by: Yun Lu <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
23 months agowifi: brcmfmac: Check for probe() id argument being NULL
Hans de Goede [Wed, 10 May 2023 14:18:56 +0000 (16:18 +0200)]
wifi: brcmfmac: Check for probe() id argument being NULL

The probe() id argument may be NULL in 2 scenarios:

1. brcmf_pcie_pm_leave_D3() calling brcmf_pcie_probe() to reprobe
   the device.

2. If a user tries to manually bind the driver from sysfs then the sdio /
   pcie / usb probe() function gets called with NULL as id argument.

1. Is being hit by users causing the following oops on resume and causing
wifi to stop working:

BUG: kernel NULL pointer dereference, address: 0000000000000018
<snip>
Hardware name: Dell Inc. XPS 13 9350/0PWNCR, BIDS 1.13.0 02/10/2020
Workgueue: events_unbound async_run_entry_fn
RIP: 0010:brcmf_pcie_probe+Ox16b/0x7a0 [brcmfmac]
<snip>
Call Trace:
 <TASK>
 brcmf_pcie_pm_leave_D3+0xc5/8x1a0 [brcmfmac be3b4cefca451e190fa35be8f00db1bbec293887]
 ? pci_pm_resume+0x5b/0xf0
 ? pci_legacy_resume+0x80/0x80
 dpm_run_callback+0x47/0x150
 device_resume+0xa2/0x1f0
 async_resume+0x1d/0x30
<snip>

Fix this by checking for id being NULL.

In the PCI and USB cases try a manual lookup of the id so that manually
binding the driver through sysfs and more importantly brcmf_pcie_probe()
on resume will work.

For the SDIO case there is no helper to do a manual sdio_device_id lookup,
so just directly error out on a NULL id there.

Fixes: da6d9c8ecd00 ("wifi: brcmfmac: add firmware vendor info in driver info")
Reported-by: Felix <[email protected]>
Link: https://lore.kernel.org/regressions/[email protected]/
Cc: [email protected]
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
23 months agowifi: rtw88: correct qsel_to_ep[] type as int
Ping-Ke Shih [Mon, 8 May 2023 08:55:39 +0000 (16:55 +0800)]
wifi: rtw88: correct qsel_to_ep[] type as int

qsel_to_ep[] can be assigned negative value, so change type from 'u8' to
'int'. Otherwise, Smatch static checker warns:
  drivers/net/wireless/realtek/rtw88/usb.c:219 rtw_usb_parse() warn:
  assigning (-22) to unsigned variable 'rtwusb->qsel_to_ep[8]'

Cc: [email protected]
Fixes: a6f187f92bcc ("wifi: rtw88: usb: fix priority queue to endpoint mapping")
Reported-by: Dan Carpenter <[email protected]>
Link: https://lore.kernel.org/linux-wireless/[email protected]/
Cc: Sascha Hauer <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Acked-by: Sascha Hauer <[email protected]>
Tested-by: Larry Finger <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
23 months agobpf: Remove anonymous union in bpf_kfunc_call_arg_meta
Dave Marchevsky [Wed, 10 May 2023 21:30:47 +0000 (14:30 -0700)]
bpf: Remove anonymous union in bpf_kfunc_call_arg_meta

For kfuncs like bpf_obj_drop and bpf_refcount_acquire - which take
user-defined types as input - the verifier needs to track the specific
type passed in when checking a particular kfunc call. This requires
tracking (btf, btf_id) tuple. In commit 7c50b1cb76ac
("bpf: Add bpf_refcount_acquire kfunc") I added an anonymous union with
inner structs named after the specific kfuncs tracking this information,
with the goal of making it more obvious which kfunc this data was being
tracked / expected to be tracked on behalf of.

In a recent series adding a new user of this tuple, Alexei mentioned
that he didn't like this union usage as it doesn't really help with
readability or bug-proofing ([0]). In an offline convo we agreed to
have the tuple be fields (arg_btf, arg_btf_id), with comments in
bpf_kfunc_call_arg_meta definition enumerating the uses of the fields by
kfunc-specific handling logic. Such a pattern is used by struct
bpf_reg_state without trouble.

Accordingly, this patch removes the anonymous union in favor of arg_btf
and arg_btf_id fields and comment enumerating their current uses. The
patch also removes struct btf_and_id, which was only being used by the
removed union's inner structs.

This is a mechanical change, existing linked_list and rbtree tests will
validate that correct (btf, btf_id) are being passed.

  [0]: https://lore.kernel.org/bpf/20230505021707[email protected]

Signed-off-by: Dave Marchevsky <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
This page took 0.140876 seconds and 4 git commands to generate.