In order to de-const variables simply casting through (void *) is
not enough: "cast from 'const .. *' to 'void *' drops const qualifier".
Cast through (uintptr_t) as well [1] to make this compile on systems
with more strict requirements.
In addition passing const void *data to dma_map_single() also
drops the (const) qualifier.  De-constify on variable on assignment
which may be overwritten later.  In either case the (void *) cast
to dma_map_single() is not needed (anymore) either.

[1] See __DECONST() in sys/sys/cdefs.h in FreeBSD

Sponsored by:  The FreeBSD Foundation
Signed-off-by: NBjoern A. Zeeb <bz@FreeBSD.ORG>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220128153014.eb696eb56bf6.Ide1dd041f9b908c5154a600286a7453750b0704a@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Instead of taking the group/command separately, make the function
take a combined command ID. In many cases, this allows us to pass
an existing command ID (e.g. cmd.id), or introduce a new variable
for it, so that we don't use the command ID twice.

This way, we can also use LONG_GROUP implicitly, so we don't need
to spell that out for many commands.

Apart from mvm.h, fw/img.{c,h} changes and some copyright and
indentation updates, this was done with spatch:

    @@
    identifier cmd;
    expression fw, G, C, def;
    @@
     struct iwl_host_cmd cmd = {
      .id = WIDE_ID(G, C),
    ...
     };
    ...
    -iwl_fw_lookup_cmd_ver(fw, G, C, def)
    +iwl_fw_lookup_cmd_ver(fw, cmd.id, def)

    @@
    identifier cmd;
    expression fw, C, def;
    @@
     struct iwl_host_cmd cmd = {
      .id = C,
    ...
     };
    ...
    -iwl_fw_lookup_cmd_ver(fw, \(IWL_ALWAYS_LONG_GROUP\|LONG_GROUP\), C, def)
    +iwl_fw_lookup_cmd_ver(fw, cmd.id, def)

    @@
    identifier func;
    expression fw, G, C, mvm, flags, cmd, size, def;
    type rettype;
    @@
    rettype func(...)
    {
    +u32 cmd_id = WIDE_ID(G, C);
    ...
    -iwl_fw_lookup_cmd_ver(fw, G, C, def)
    +iwl_fw_lookup_cmd_ver(fw, cmd_id, def)
    ...
    -iwl_mvm_send_cmd_pdu(mvm, WIDE_ID(G, C), flags, cmd, size)
    +iwl_mvm_send_cmd_pdu(mvm, cmd_id, flags, cmd, size)
    ...
    }

    @@
    identifier func;
    expression fw, G, C, mvm, flags, cmd, size, def;
    type rettype;
    @@
    rettype func(...)
    {
    +u32 cmd_id = C;
    ...
    -iwl_fw_lookup_cmd_ver(fw, \(IWL_ALWAYS_LONG_GROUP\|LONG_GROUP\), C, def)
    +iwl_fw_lookup_cmd_ver(fw, cmd_id, def)
    ...
    -iwl_mvm_send_cmd_pdu(mvm, C, flags, cmd, size)
    +iwl_mvm_send_cmd_pdu(mvm, cmd_id, flags, cmd, size)
    ...
    }

    @@
    expression fw, C, def;
    @@
    -iwl_fw_lookup_cmd_ver(fw, \(IWL_ALWAYS_LONG_GROUP\|LONG_GROUP\), C, def)
    +iwl_fw_lookup_cmd_ver(fw, C, def)

    @@
    expression fw, C, G, def;
    @@
    -iwl_fw_lookup_cmd_ver(fw, G, C, def)
    +iwl_fw_lookup_cmd_ver(fw, WIDE_ID(G, C), def)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220128153014.c4ac213cef5c.I6fd9a4fcbcf16ef3a3ae20a2b08ee54ebe06f96f@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

This is valid, but pretty uncommon in the driver, clean up
the code here a bit to use an initializer.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220128153014.1717817392df.I75add2a50a69d28eaebfd67e5a0524bf43119a81@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

The order of arguments for iwl_cmd_id() is confusing, and the
version is always 0 and thus a useless argument. Prefer the
WIDE_ID() macro (which needs to be a macro due to use in switch
cases etc.) over the iwl_cmd_id() function.

Obviously done with spatch:

  @@
  expression G, C;
  @@
  -iwl_cmd_id(C, G, 0)
  +WIDE_ID(G, C)
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220128153014.cc4f9d1a2e9b.Ieb023cd773ea22e819d1ef1c37ae857ecc1a839d@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Read a new bit defined in ACPI WTAS that allows OEMs to specify whether
TAS is allowed in UHB (6-7GHz) in the USA.  This can be used by OEMs
that got certified to use this feature.
Signed-off-by: NAyala Barazani <ayala.barazani@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220128153014.1d2ae1e6bcdb.I177929ed01ed7bf4614ea0f6db2af9e52de13316@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Since FW is now in charge of timing the channel switch, there is no need
to send the add/modify/remove time event command to fw with every (e)CSA
element.
However, the driver needs to cancel the channel switch if the CS start
notification arrives and it does not know about an ongoing channel switch.
Signed-off-by: NNathan Errera <nathan.errera@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20220128153013.ac3af0ff22c7.Ie87c62047b71b93b12aa80b5dc5391b4798dbe97@changeidSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

The recent fix for NULL sta in iwl_mvm_get_tx_rate() still has a call
of iwl_mvm_sta_from_mac80211() that may be called with NULL sta.
Although this practically only points to the address and the actual
access doesn't happen due to the conditional evaluation at a later
point, it looks a bit flaky.

This patch drops the temporary variable above and evaluates
iwm_mvm_sta_from_mac80211() directly for avoiding confusions.

Fixes: d599f714 ("iwlwifi: mvm: don't crash on invalid rate w/o STA")
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20220121114024.10454-1-tiwai@suse.deSigned-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add EHT capabilities to bands.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Link: https://lore.kernel.org/r/20220214173004.1b710f8e04ce.I11d6911dafc01deb8ceb7828e363e8554701790a@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add initial support for EHT and 320 MHz bandwidth in mac80211.

As a new IEEE80211_STA_RX_BW_320 is added to
enum ieee80211_sta_rx_bandwidth, update the drivers to avoid
compilation warnings.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Link: https://lore.kernel.org/r/20220214173004.0f144cc0bba6.Iad18111264da87eed5fd7b017f0cc6e58c604e07@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add 320 MHz support in the channel def and center frequency validation
with compatible check.
Signed-off-by: NJia Ding <quic_jiad@quicinc.com>
Co-authored-by: NKarthikeyan Periyasamy <quic_periyasa@quicinc.com>
Signed-off-by: NKarthikeyan Periyasamy <quic_periyasa@quicinc.com>
Co-authored-by: NMuna Sinada <quic_msinada@quicinc.com>
Signed-off-by: NMuna Sinada <quic_msinada@quicinc.com>
Co-authored-by: NVeerendranath Jakkam <quic_vjakkam@quicinc.com>
Signed-off-by: NVeerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://lore.kernel.org/r/1640163883-12696-5-git-send-email-quic_vjakkam@quicinc.com
Link: https://lore.kernel.org/r/20220214163009.175289-1-johannes@sipsolutions.netSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

We add the fields for parsing extended ADDBA request/respond,
and new max 1K aggregation for limit ADDBA request/respond.

Adjust drivers to use the proper macro, IEEE80211_MAX_AMPDU_BUF ->
IEEE80211_MAX_AMPDU_BUF_HE.
Signed-off-by: NMordechay Goodstein <mordechay.goodstein@intel.com>
Link: https://lore.kernel.org/r/20220214173004.b8b447ce95b7.I0ee2554c94e89abc7a752b0f7cc7fd79c273efea@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add a custom regulatory domain for testing 6 GHz, including
320 MHz bandwidth. This can be used before the regulatory
databases are all updated etc.
Signed-off-by: NIlan Peer <ilan.peer@intel.com>
Link: https://lore.kernel.org/r/20220214173004.e3d6faf1f35f.I9507395b64496d96a2276ba8c1e1323e54407aa7@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

The argument to hwsim_init_s1g_channels() shadows a global,
change that to be clearer.

Link: https://lore.kernel.org/r/20220214173004.66bac90d64a8.I3e878e42bf2feecbb0a6ca38a68c236c23a8c9e6@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Add checks to hwsim to validate that neither TX nor any
station's configured bandwidth can exceed the channel
(context) configuration previously requested.

Link: https://lore.kernel.org/r/20220214173004.9fd154d2c3c2.Ia0cd152357a373149bab017d479ab7d5ded289c0@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Set the base RSSI of a TX frame. The final RSSI of the frame will be
the base RSSI + the radio's TX power
Signed-off-by: NBeni Lev <beni.lev@intel.com>
Link: https://lore.kernel.org/r/20220210201649.dddebbb55a7f.I6c0607694587b577070339078829fcc20dfcfe2c@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>

Apply 160M bandwidth to RA (rate adaptive) mechanism, so it can transmit
packets with this bandwidth. On the other hand, convert 160M bandwidth
from RX desc to rx_info_bw.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220211075953.40421-7-pkshih@realtek.com

The new chip can support 160M, so add a chip attribute to indicate the
chip support it.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220211075953.40421-6-pkshih@realtek.com

Construct rate mask of 6G band, and rate adaptive mechanism can work well
on this band.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220211075953.40421-5-pkshih@realtek.com

Split 6G band into 8 sub-bands where indexes are from 0 to 7,
i.e. RTW89_CH_6G_BAND_IDX[0-7]. Then, decide subband by both
band and channel instead of just channel because conflicts
between 5G channels and 6G channels.

Moreover, add default case to the existing use of switch (subband).
Signed-off-by: NZong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220211075953.40421-4-pkshih@realtek.com

Since these macro in rfk helpers are common now, a common naming
should be better. So, apply RTW89_ as prefix to them, and modify
the use correspondly. No logic is changed at all.
Signed-off-by: NZong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220211075953.40421-3-pkshih@realtek.com

These rfk helpers are also useful for the chip which is under planning.
So, move them to common code to avoid duplicate stuff in the future.
Signed-off-by: NZong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220211075953.40421-2-pkshih@realtek.com

BCM43454/6 is a variant of BCM4345 which is exactly identical to
BCM4345/6, except the chip id is 0xa9be. This patch adds support
for BCM43454/6 by handing it in the same way as BCM4345.

Note: when loading some specific version of BCM4345 firmware, the
chip id may become 0x4345. This is an expected behavior, and it will
restore to 0xa9be after power cycle.
Signed-off-by: NJiaqing Zhao <jiaqing.zhao@intel.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/CO1PR11MB47859B51BCA88613D1582EB88E2E9@CO1PR11MB4785.namprd11.prod.outlook.com

The mv88e6352, mv88e6240 and mv88e6176  have a serdes interface. This patch
allows to configure the output swing to a desired value in the
phy-handle of the port. The value which is peak to peak has to be
specified in microvolts. As the chips only supports eight dedicated
values we return EINVAL if the value in the DTS does not match one of
these values.
Signed-off-by: NHolger Brunck <holger.brunck@hitachienergy.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since struct mv88e6xxx_mdio_bus *mdio_bus is the bus->priv of something
allocated with mdiobus_alloc_size(), this means that mdiobus_free(bus)
will free the memory backing the mdio_bus as well. Therefore, the
mdio_bus->list element is freed memory, but we continue to iterate
through the list of MDIO buses using that list element.

To fix this, use the proper list iterator that handles element deletion
by keeping a copy of the list element next pointer.

Fixes: f53a2ce8 ("net: dsa: mv88e6xxx: don't use devres for mdiobus")
Reported-by: NRafael Richter <rafael.richter@gin.de>
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20220210174017.3271099-1-vladimir.oltean@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

An ongoing workqueue populates the stats buffer. At the same time, a user
might query the statistics. While writing to the buffer is mutex-locked,
reading from the buffer wasn't. This could lead to buggy reads by ethtool.

This patch fixes the former blamed commit, but the bug was introduced in
the latter.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Fixes: 1e1caa97 ("ocelot: Clean up stats update deferred work")
Fixes: a556c76a ("net: mscc: Add initial Ocelot switch support")
Reported-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/all/20220210150451.416845-2-colin.foster@in-advantage.com/Signed-off-by: NJakub Kicinski <kuba@kernel.org>

drivers/net/dsa/qca8k.c:422:37-43: ERROR: application of sizeof to pointer

 sizeof when applied to a pointer typed expression gives the size of
 the pointer

Generated by: scripts/coccinelle/misc/noderef.cocci

Fixes: 90386223 ("net: dsa: qca8k: add support for larger read/write size with mgmt Ethernet")
CC: Ansuel Smith <ansuelsmth@gmail.com>
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: Nkernel test robot <lkp@intel.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20220209221304.GA17529@d2214a582157Signed-off-by: NJakub Kicinski <kuba@kernel.org>

If a call to re-create the auxiliary device happens in a context that has
already taken the RTNL lock, then the call flow that recreates auxiliary
device can hang if there is another attempt to claim the RTNL lock by the
auxiliary driver.

To avoid this, any call to re-create auxiliary devices that comes from
an source that is holding the RTNL lock (e.g. netdev notifier when
interface exits a bond) should execute in a separate thread.  To
accomplish this, add a flag to the PF that will be evaluated in the
service task and dealt with there.

Fixes: f9f5301e ("ice: Register auxiliary device to provide RDMA")
Signed-off-by: NDave Ertman <david.m.ertman@intel.com>
Reviewed-by: NJonathan Toppins <jtoppins@redhat.com>
Tested-by: NGurucharan G <gurucharanx.g@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>

Currently, the same handler is called for both a NETDEV_BONDING_INFO
LAG unlink notification as for a NETDEV_UNREGISTER call.  This is
causing a problem though, since the netdev_notifier_info passed has
a different structure depending on which event is passed.  The problem
manifests as a call trace from a BUG: KASAN stack-out-of-bounds error.

Fix this by creating a handler specific to NETDEV_UNREGISTER that only
is passed valid elements in the netdev_notifier_info struct for the
NETDEV_UNREGISTER event.

Also included is the removal of an unbalanced dev_put on the peer_netdev
and related braces.

Fixes: 6a8b3572 ("ice: Respond to a NETDEV_UNREGISTER event for LAG")
Signed-off-by: NDave Ertman <david.m.ertman@intel.com>
Acked-by: NJonathan Toppins <jtoppins@redhat.com>
Tested-by: NSunitha Mekala <sunithax.d.mekala@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>

The driver was avoiding offload for IPIP (at least) frames due to
parsing the inner header offsets incorrectly when trying to check
lengths.

This length check works for VXLAN frames but fails on IPIP frames
because skb_transport_offset points to the inner header in IPIP
frames, which meant the subtraction of transport_header from
inner_network_header returns a negative value (-20).

With the code before this patch, everything continued to work, but GSO
was being used to segment, causing throughputs of 1.5Gb/s per thread.
After this patch, throughput is more like 10Gb/s per thread for IPIP
traffic.

Fixes: e94d4478 ("ice: Implement filter sync, NDO operations and bump version")
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Reviewed-by: NPaul Menzel <pmenzel@molgen.mpg.de>
Tested-by: NGurucharan G <gurucharanx.g@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>

Propagate the error code from ice_get_link_default_override() instead
of returning success.

Fixes: ea78ce4d ("ice: add link lenient and default override support")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Tested-by: NGurucharan G <gurucharanx.g@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>

This patch adds TC feature for VFs also. When MCAM
rules are allocated for a VF then either TC or ntuple
filters can be used. Below are the commands to use
TC feature for a VF(say lbk0):

devlink dev param set pci/0002:01:00.1 name mcam_count value 16 \
 cmode runtime
ethtool -K lbk0 hw-tc-offload on
ifconfig lbk0 up
tc qdisc add dev lbk0 ingress
tc filter add dev lbk0 parent ffff: protocol ip flower skip_sw \
 dst_mac 98:03:9b:83:aa:12 action police rate 100Mbit burst 5000

Also to modify any fields of the hardware context with
NIX_AQ_INSTOP_WRITE command then corresponding masks of those
fields must be set as per hardware. This was missing in
ingress ratelimiting context. This patch sets those masks also.
Signed-off-by: NSubbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: NSunil Goutham <sgoutham@marvell.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Device firmware can assert if the device shutdown path in driver
encounters an async. events from mfw (processed in
qed_mcp_handle_events()) after qed_mcp_unload_req() returns.
A call to qed_mcp_unload_req() currently marks the device as inactive
and thus stops any new events, but there is a windows where in-flight
events might still be received by the driver.

To prevent this race condition, atomically set QED_MCP_BYPASS_PROC_BIT
in qed_mcp_unload_req() to make sure qed_mcp_handle_events() ignores all
events. Wait for any event that might already be in-process to complete
by monitoring QED_MCP_IN_PROCESSING_BIT.
Signed-off-by: NPravin Kumar Ganesh Dhende <pdhende@marvell.com>
Signed-off-by: NVenkata Sudheer Kumar Bhavaraju <vbhavaraju@marvell.com>
Signed-off-by: NAlok Prasad <palok@marvell.com>
Signed-off-by: NAriel Elior <aelior@marvell.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The netdev should be unregistered before we are disconnecting from the
MAC/PHY so that the dev_close callback is called and the PHY and the
phylink workqueues are actually stopped before we are disconnecting and
destroying the phylink instance.

Fixes: 71947923 ("dpaa2-eth: add MAC/PHY support through phylink")
Signed-off-by: NRobert-Ionut Alexa <robert-ionut.alexa@nxp.com>
Signed-off-by: NIoana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Single page and coherent memory blocks can use different DMA masks
when the macb accesses physical memory directly. The kernel is clever
enough to allocate pages that fit into the requested address width.

When using the ARM SMMU, the DMA mask must be the same for single
pages and big coherent memory blocks. Otherwise the translation
tables turn into one big mess.

  [   74.959909] macb ff0e0000.ethernet eth0: DMA bus error: HRESP not OK
  [   74.959989] arm-smmu fd800000.smmu: Unhandled context fault: fsr=0x402, iova=0x3165687460, fsynr=0x20001, cbfrsynra=0x877, cb=1
  [   75.173939] macb ff0e0000.ethernet eth0: DMA bus error: HRESP not OK
  [   75.173955] arm-smmu fd800000.smmu: Unhandled context fault: fsr=0x402, iova=0x3165687460, fsynr=0x20001, cbfrsynra=0x877, cb=1

Since using the same DMA mask does not hurt direct 1:1 physical
memory mappings, this commit always aligns DMA and coherent masks.
Signed-off-by: NMarc St-Amand <mstamand@ciena.com>
Signed-off-by: NHarini Katakam <harini.katakam@xilinx.com>
Acked-by: NNicolas Ferre <nicolas.ferre@microchip.com>
Tested-by: NConor Dooley <conor.dooley@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The variable len is being assigned bit is never used. The variable
and the strlen call are redundant and can be removed.
Signed-off-by: NColin Ian King <colin.i.king@gmail.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207133329.336664-1-colin.i.king@gmail.com

There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].

This helps with the ongoing efforts to globally enable -Warray-bounds
and get us closer to being able to tighten the FORTIFY_SOURCE routines
on memcpy().

This issue was found with the help of Coccinelle and audited and fixed,
manually.

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays

Link: https://github.com/KSPP/linux/issues/79Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220204232228.GA442895@embeddedor

B_AX_PLT_EN is to enable polluted mechanism. If it is enabled and
gnt_bt = 1 while wlan TX, B_AX_BT_PLT_PKT_CNT counter will increase,
but TX counter to BB will not. Without this bit BTCoex mechanism might
have some problems.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220208082751.43553-1-pkshih@realtek.com

Some APs like CMW270 only support one phyrate and the function
rtw89_phy_ra_mask_rssi could disable that rate. To fix such problem, we
restore the rate mask if we find that the rate_mask is empty.
Also, apply missed legacy rates from sta->supp_rates[].
Signed-off-by: NChien-Hsun Liao <ben.liao@realtek.com>
Signed-off-by: NKuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220208082427.42433-3-pkshih@realtek.com

Some APs like CMW270 only support one phyrate and the function
rtw_update_rate_mask could disable that rate. To fix such problem, we
restore the rate mask if we find that the rate_mask is empty.
Signed-off-by: NChien-Hsun Liao <ben.liao@realtek.com>
Signed-off-by: NKuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220208082427.42433-2-pkshih@realtek.com

Things are ready for AP mode, so declare this driver can support it.
Signed-off-by: NPing-Ke Shih <pkshih@realtek.com>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220207063900.43643-8-pkshih@realtek.com