When we remove a station, we first make it unreachable,
then we (must) remove its keys, and then remove the
station itself. Depending on the hardware design, if
we have hardware crypto at all, frames still sitting
on hardware queues may then be transmitted without a
valid key, possibly unencrypted or with a fixed key.

Fix this by flushing the queues when removing stations
so this cannot happen.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The checks of whether or not a frame is bufferable were not
taking into account that some action frames aren't, such as
FTM. Check this, which requires some changes to the function
ieee80211_is_bufferable_mmpdu() since we need the whole skb
for the checks now.

Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

WLAN_PUBLIC_ACTION_FTM_RESPONSE is duplicated with
WLAN_PUB_ACTION_FTM, but that might better be called
WLAN_PUB_ACTION_FTM_RESPONSE; clean up here.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

On Bz devices, CHECKSUM_COMPLETE was set for unsupported protocols
which results in a warning. Fix it.

Fixes: b6f5b647

 ("iwlwifi: mvm: handle RX checksum on Bz devices")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.a2a35286f0ca.I50daa9445a6465514c44f5096c32adef64beba5f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

When the IPC registers are used for sleep control, setting
the IPC sleep bit already triggers an interrupt to the fw, so
there is no need to also set the doorbell. Setting also the
doorbell triggers the sleep interrupt twice which lead to
an assert.

Fixes: af08571d

 ("iwlwifi: pcie: support Bz suspend/resume trigger")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.b5f2f6e44d38.I4cb5b6ad4914db47a714e731c4c8b4db679cabce@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Correction in config data is done for loading the ucode.

Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.879b654c8d83.I7dbea9f411a0b6f47908c4ad6321c7e55cbeb636@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

PHY configuration command need to be sent to FW if the tx diversity
with SISO is supported.
This need to be sent to get the init notification from FW.

Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.c2121c8694a7.Ibee3dd8765ef4b7504660fa228a7c7eff78920af@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Need to move a function definition and actual changes
will be done in following commit.

Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.00a6c203712f.I7c099e5c1954f1daa5a5039b98149b6f081e46ae@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Max A-MPDU length exponent shall be set to 2 for EHT capable
device on 6GHz band in order to support 4MB aggregation.

Update HE MAC capabilities accordingly for station and softap
interfaces.

This change requires to add another ieee80211_sband_iftype_data for
uhb since high/uhb are no longer the same.

Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.1eee32cfd199.I9c5ff3a6956d509137deca620814935149516fbc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There are two modes now, and we have two places checking
that must be in sync. Refactor the logic into a new small
helper function.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.ef6246f4b73b.I44820ec095634dd0bba3007465cf25e4ce1c77c6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Since Gl A-step devices use the old checksum hardware,
we shouldn't use the Bz code to check for A-MSDU
combining ability; fix that.

Fixes: ec18e7d4

 ("wifi: iwlwifi: mvm: use old checksum for Bz A-step")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.8c445b943fee.Ibf772102ca712f59e2ee0cdd4c344011fcf445aa@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

B step doesn't support full checksum yet, move to c step.

Signed-off-by: Golan Ben Ami <golan.ben.ami@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.697a9d74e84d.I6724874112692a04e29287cac9dad7140532557f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

IEEE80211_TX_CTL_NO_CCK_RATE indicates that CCK rates should not be
used, but is ignored by the driver. Fix it.

Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.a322d18b5eb1.Icc46027a03f90feffb6fab49a5d82e54829d3dd9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

On queue remove, we should convert the TID value to the
firmware value (8 -> 15) just like we do on queue add.
Otherwise, the firmware will not be able to find the
correct queue to remove.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.6651077eaec3.Ia6868c8fc1a92063609bb057b6a618726712d0bb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

update the device configuration for HR1 device for SO and SOF device.
QuZ device configuration is corrected to support specific CRF.

Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.86f08520323f.Ieccb50de47f877b85732000a0d67b645eeeb0c2a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

This function receives the queue id to reclaim packets from. Currently
we're passing to it the queue id we received from the FW in the flush
response. We don't do any check of this value and it might be invalid.
In such case we will refer to a pointer to a queue which might be NULL.
Fix this by adding a validity check of the queue id before using it.

Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.a9c3fd32bce7.I5fbdcf3b1b80eb96a907116c166f19dc0aae7cb8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Initially, 160/320 MHz in AP mode were not supported.
After testing, enable the wider bandwidths in AP mode
as well.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.ed04de3a2833.Ie3991179dfaf24880b96a0904a625dbf6b8fd579@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

In __iwl_err(), if we rate-limit the message away, then
vaf.va is still NULL-initialized by the time we get to
the tracing code, which then crashes. When it doesn't
get rate-limited out, it's still wrong to reuse the old
args2 that was already printed, which is why we bother
making a copy in the first place.

Assign vaf.va properly to fix this.

Fixes: e5f1cc98

 ("iwlwifi: allow rate-limited error messages")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413102635.e27134c6bcd4.Ib3894cd2ba7a5ad5e75912a7634f146ceaa569e2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Wire up RTL8821CS chipset support using the new rtw88 SDIO HCI code as
well as the existing RTL8821C chipset code.

Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-10-martin.blumenstingl@googlemail.com

Wire up RTL8822CS chipset support using the new rtw88 SDIO HCI code as
well as the existing RTL8822C chipset code.

Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-9-martin.blumenstingl@googlemail.com

Wire up RTL8822BS chipset support using the new rtw88 SDIO HCI code as
well as the existing RTL8822B chipset code.

Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-8-martin.blumenstingl@googlemail.com

Add the SDIO vendor ID for Realtek and some device IDs extracted from
their GPL vendor driver. This will be useful in the future when the
rtw88 driver gains support for these chips.

Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-7-martin.blumenstingl@googlemail.com

For SDIO host controllers with DMA support the TX buffer physical memory
address need to be aligned at an 8-byte boundary. Reserve 8 bytes of
extra TX headroom so we can align the data without re-allocating the
transmit buffer.

While here, also remove the TODO comment regarding extra headroom for
USB and SDIO. For SDIO the extra headroom is now handled and for USB it
was not needed so far.

Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-6-martin.blumenstingl@googlemail.com

Initialize the rpwm_addr and cpwm_addr for power-saving support on SDIO
based chipsets.

Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-5-martin.blumenstingl@googlemail.com

Add the code specific to SDIO HCI in the MAC power on sequence. This is
based on the RTL8822BS and RTL8822CS vendor drivers.

Co-developed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-4-martin.blumenstingl@googlemail.com

Add a sub-driver for SDIO based chipsets which implements the following
functionality:
- register accessors for 8, 16 and 32 bits for all states of the card
  (including usage of 4x 8 bit access for one 32 bit buffer if the card
  is not fully powered on yet - or if it's fully powered on then 1x 32
  bit access is used)
- checking whether there's space in the TX FIFO queue to transmit data
- transfers from the host to the device for actual network traffic,
  reserved pages (for firmware download) and H2C (host-to-card)
  transfers
- receiving data from the device
- deep power saving state

The transmit path is optimized so DMA-capable SDIO host controllers can
directly use the buffers provided because the buffer's physical
addresses are 8 byte aligned.

The receive path is prepared to support RX aggregation where the
chipset combines multiple MAC frames into one bigger buffer to reduce
SDIO transfer overhead.

Co-developed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-3-martin.blumenstingl@googlemail.com

The SDIO HCI implementation needs to know when the MAC is powered on.
This is needed because 32-bit register access has to be split into 4x
8-bit register access when the MAC is not fully powered on or while
powering off. When the MAC is powered on 32-bit register access can be
used to reduce the number of transfers but splitting into 4x 8-bit
register access still works in that case.

During the power on sequence is how RTW_FLAG_POWERON is only set when
the power on sequence has completed successfully. During power off
however RTW_FLAG_POWERON is set. This means that the upcoming SDIO HCI
implementation does not know that it has to use 4x 8-bit register
accessors. Clear the RTW_FLAG_POWERON flag early when powering off the
MAC so the whole power off sequence is processed with RTW_FLAG_POWERON
unset. This will make it possible to use the RTW_FLAG_POWERON flag in
the upcoming SDIO HCI implementation.

Note that a failure in rtw_pwr_seq_parser() while applying
chip->pwr_off_seq can theoretically result in the RTW_FLAG_POWERON
flag being cleared while the chip is still powered on. However,
depending on when the failure occurs in the power off sequence the
chip may be on or off. Even the original approach of clearing
RTW_FLAG_POWERON only when the power off sequence has been applied
successfully could end up in some corner case where the chip is
powered off but RTW_FLAG_POWERON was not cleared.

Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230405200729.632435-2-martin.blumenstingl@googlemail.com

Set 'eht_support' flag if EHT capabilities are present.

Signed-off-by: Aloka Dixit <quic_alokad@quicinc.com>
Link: https://lore.kernel.org/r/20230410200332.32265-1-quic_alokad@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

syzbot reported a NULL dereference caused by a missing check
in hwsim_pmsr_report_nl(), and bisected the issue to cited commit.

v2: test the nlattr before using nla_data() on it (Simon Horman)

general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 5084 Comm: syz-executor104 Not tainted 6.3.0-rc4-next-20230331-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
RIP: 0010:jhash+0x339/0x610 include/linux/jhash.h:95
Code: 83 fd 01 0f 84 5f ff ff ff eb de 83 fd 05 74 3a e8 ac f5 71 fd 48 8d 7b 05 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 96 02 00 00
RSP: 0018:ffffc90003abf298 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffffff84111ba4 RDI: 0000000000000009
RBP: 0000000000000006 R08: 0000000000000005 R09: 000000000000000c
R10: 0000000000000006 R11: 0000000000000000 R12: 000000004d2c27cd
R13: 000000002bd9e6c2 R14: 000000002bd9e6c2 R15: 000000002bd9e6c2
FS: 0000555556847300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000045ad50 CR3: 0000000078aa6000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
rht_key_hashfn include/linux/rhashtable.h:159 [inline]
__rhashtable_lookup include/linux/rhashtable.h:604 [inline]
rhashtable_lookup include/linux/rhashtable.h:646 [inline]
rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]
get_hwsim_data_ref_from_addr+0xb9/0x600 drivers/net/wireless/virtual/mac80211_hwsim.c:757
hwsim_pmsr_report_nl+0xe7/0xd50 drivers/net/wireless/virtual/mac80211_hwsim.c:3764
genl_family_rcv_msg_doit.isra.0+0x1e6/0x2d0 net/netlink/genetlink.c:968
genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
genl_rcv_msg+0x4ff/0x7e0 net/netlink/genetlink.c:1065
netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2572
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
sock_sendmsg_nosec net/socket.c:724 [inline]
sock_sendmsg+0xde/0x190 net/socket.c:747
____sys_sendmsg+0x71c/0x900 net/socket.c:2501
___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
__sys_sendmsg+0xf7/0x1c0 net/socket.c:2584
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

Fixes: 2af3b2a6

 ("mac80211_hwsim: add PMSR report support via virtio")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jaewan Kim <jaewan@google.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Jaewan Kim <jaewan@google.com>
Link: https://lore.kernel.org/r/20230404171658.917361-1-edumazet@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

There're two identical entries for ax1650 device in
iwl_dev_info_table. Remove one of the duplicate entries.

Fixes: 953e66a7

 ("iwlwifi: add new ax1650 killer device")
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230410140721.897683-2-gregory.greenman@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Host commands and notifications are expected to be ordered in
iwl_mvm_groups array. Fix the order of two new TIMING_MEASUREMENT
notifications.

Fixes: c7eca79d

 ("wifi: iwlwifi: mvm: report hardware timestamps in RX/TX status")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/linux-wireless/20230331175121.GA3127046@dev-arch.thelio-3990X/
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20230410140721.897683-1-gregory.greenman@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

The patch addresses an issue with the reset logic on the i.MX93 SoC, which
requires configuration of the correct interface speed under RMII mode to
complete the reset. The patch implements a fix_soc_reset function and uses
it specifically for the i.MX93 SoCs.

Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230403222302.328262-2-shenwei.wang@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

This patch adds support for platform-specific reset logic in the
stmmac driver. Some SoCs require a different reset mechanism than
the standard dwmac IP reset. To support these platforms, a new function
pointer 'fix_soc_reset' is added to the plat_stmmacenet_data structure.
The stmmac_reset in hwif.h is modified to call the 'fix_soc_reset'
function if it exists. This enables the driver to use the platform-specific
reset logic when necessary.

Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230403222302.328262-1-shenwei.wang@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

For the sake of readability, use the netlink payload helpers from
the 'nla_get_*()' family to parse the attributes.

tdc results:
1..5
ok 1 9903 - Add mqprio Qdisc to multi-queue device (8 queues)
ok 2 453a - Delete nonexistent mqprio Qdisc
ok 3 5292 - Delete mqprio Qdisc twice
ok 4 45a9 - Add mqprio Qdisc to single-queue device
ok 5 2ba9 - Show mqprio class

Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Pedro Tammela <pctammela@mojatatu.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230404203449.1627033-1-pctammela@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

There's no need for "#address-cells/#size-cells" in the brcm,sf2 node as
no immediate child nodes have an address. What was probably intended was
to put them in the 'ports' node, but that's not necessary as that is
covered by ethernet-switch.yaml via dsa.yaml.

Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230404204152.635400-1-robh@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

The schema doesn't allow for a single (unaddressed) ethernet port node
nor does a single port switch make much sense. So if there's always
multiple child nodes, "#address-cells" and "#size-cells" should be
required.

Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20230404204213.635773-1-robh@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge tag 'wireless-next-2023-04-05' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

Kalle Valo says:

====================
wireless-next patches for v6.3

Smaller pull request this time, sending this early to fix the conflict
in mac80211. Nothing really special this time, only smaller changes.

 * enable Wi-Fi 7 (EHT) mesh support

* tag 'wireless-next-2023-04-05' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (37 commits)
  wifi: rt2x00: Fix memory leak when handling surveys
  wifi: b43legacy: Remove the unused function prev_slot()
  wifi: rtw89: Remove redundant pci_clear_master
  wifi: rtw89: fix potential race condition between napi_init and napi_enable
  wifi: rtw89: config EDCCA threshold during scan to prevent TX failed
  wifi: rtw89: fix incorrect channel info during scan due to ppdu_sts filtering
  wifi: rtw89: remove superfluous H2C of join_info
  wifi: rtw89: set data lowest rate according to AP supported rate
  wifi: rtw89: add counters of register-based H2C/C2H
  wifi: rtw89: coex: Update Wi-Fi Bluetooth coexistence version to 7.0.1
  wifi: rtw89: coex: Add report control v5 variation
  wifi: rtw89: coex: Update RTL8852B LNA2 hardware parameter
  wifi: rtw89: coex: Not to enable firmware report when WiFi is power saving
  wifi: rtw89: coex: Add LPS protocol radio state for RTL8852B
  bcma: remove unused mips_read32 function
  bcma: Use of_address_to_resource()
  wifi: mwifiex: remove unused evt_buf variable
  wifi: brcmsmac: ampdu: remove unused suc_mpdu variable
  wifi: rtlwifi: fix incorrect error codes in rtl_debugfs_set_write_reg()
  wifi: rtlwifi: fix incorrect error codes in rtl_debugfs_set_write_rfreg()
  ...
====================

Link: https://lore.kernel.org/r/20230405111037.4792BC43443@smtp.kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge tag 'linux-can-next-for-6.4-20230404-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next

Marc Kleine-Budde says:

====================
pull-request: can-next 2023-04-04-2

The first patch is by Oliver Hartkopp and makes the maximum pdu size
of the CAN ISOTP protocol configurable.

The following 5 patches are by Dario Binacchi and add support for the
bxCAN controller by ST.

Geert Uytterhoeven's patch for the rcar_canfd driver fixes a sparse
warning.

Peng Fan's patch adds an optional power-domains property to the
flexcan device tree binding.

Frank Jungclaus adds support for CAN_CTRLMODE_BERR_REPORTING to the
esd_usb driver.

The last patch is by Oliver Hartkopp and converts the USB IDs of the
kvaser_usb driver to hexadecimal values.

* tag 'linux-can-next-for-6.4-20230404-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
  kvaser_usb: convert USB IDs to hexadecimal values
  can: esd_usb: Add support for CAN_CTRLMODE_BERR_REPORTING
  dt-bindings: can: fsl,flexcan: add optional power-domains property
  can: rcar_canfd: rcar_canfd_probe(): fix plain integer in transceivers[] init
  can: bxcan: add support for ST bxCAN controller
  ARM: dts: stm32: add pin map for CAN controller on stm32f4
  ARM: dts: stm32: add CAN support on stm32f429
  dt-bindings: net: can: add STM32 bxcan DT bindings
  dt-bindings: arm: stm32: add compatible for syscon gcan node
  can: isotp: add module parameter for maximum pdu size
====================

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

The arguments passed to the trace events are of type unsigned int,
however the signature of the events used __le32 parameters.

I may be missing the point here, but sparse flagged this and it
does seem incorrect to me.

  net/qrtr/ns.c: note: in included file (through include/trace/trace_events.h, include/trace/define_trace.h, include/trace/events/qrtr.h):
  ./include/trace/events/qrtr.h:11:1: warning: cast to restricted __le32
  ./include/trace/events/qrtr.h:11:1: warning: restricted __le32 degrades to integer
  ./include/trace/events/qrtr.h:11:1: warning: restricted __le32 degrades to integer
  ... (a lot more similar warnings)
  net/qrtr/ns.c:115:47:    expected restricted __le32 [usertype] service
  net/qrtr/ns.c:115:47:    got unsigned int service
  net/qrtr/ns.c:115:61: warning: incorrect type in argument 2 (different base types)
  ... (a lot more similar warnings)

Fixes: dfddb540

 ("net: qrtr: Add tracepoint support")
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20230402-qrtr-trace-types-v1-1-92ad55008dd3@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Enable EDPD PHY tunable support for the G12A internal PHY, reusing the
recently added tunable support in the smsc driver.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/8d309575-067c-7321-33cf-6ffac11f7c8d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>