1. 23 May, 2022 14 commits
    • Vladimir Oltean's avatar
      net: dsa: felix: tag_8021q preparation for multiple CPU ports · a4e044dc
      Vladimir Oltean authored
      Update the VCAP filters to support multiple tag_8021q CPU ports.
      
      TX works using a filter for VLAN ID on the ingress of the CPU port, with
      a redirect and a VLAN pop action. This can be updated trivially by
      amending the ingress port mask of this rule to match on all tag_8021q
      CPU ports.
      
      RX works using a filter for ingress port on the egress of the CPU port,
      with a VLAN push action. Here we need to replicate these filters for
      each tag_8021q CPU port, and let them all have the same action.
      This means that the OCELOT_VCAP_ES0_TAG_8021Q_RXVLAN() cookie needs to
      encode a unique value for every {user port, CPU port} pair it's given.
      Do this by encoding the CPU port in the upper 16 bits of the cookie, and
      the user port in the lower 16 bits.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4e044dc
    • Vladimir Oltean's avatar
      net: mscc: ocelot: switch from {,un}set to {,un}assign for tag_8021q CPU ports · c295f983
      Vladimir Oltean authored
      There is a desire for the felix driver to gain support for multiple
      tag_8021q CPU ports, but the current model prevents it.
      
      This is because ocelot_apply_bridge_fwd_mask() only takes into
      consideration whether a port is a tag_8021q CPU port, but not whose CPU
      port it is.
      
      We need a model where we can have a direct affinity between an ocelot
      port and a tag_8021q CPU port. This serves as the basis for multiple CPU
      ports.
      
      Declare a "dsa_8021q_cpu" backpointer in struct ocelot_port which
      encodes that affinity. Repurpose the "ocelot_set_dsa_8021q_cpu" API to
      "ocelot_assign_dsa_8021q_cpu" to express the change of paradigm.
      
      Note that this change makes the first practical use of the new
      ocelot_port->index field in ocelot_port_unassign_dsa_8021q_cpu(), where
      we need to remove the old tag_8021q CPU port from the reserved VLAN range.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c295f983
    • Vladimir Oltean's avatar
      net: dsa: felix: directly call ocelot_port_{set,unset}_dsa_8021q_cpu · 8c166acb
      Vladimir Oltean authored
      Absorb the final details of calling ocelot_port_{,un}set_dsa_8021q_cpu(),
      i.e. the need to lock &ocelot->fwd_domain_lock, into the callee, to
      simplify the caller and permit easier code reuse later.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c166acb
    • Vladimir Oltean's avatar
      net: dsa: felix: update bridge fwd mask from ocelot lib when changing tag_8021q CPU · a72e23dd
      Vladimir Oltean authored
      Add more logic to ocelot_port_{,un}set_dsa_8021q_cpu() from the ocelot
      switch lib by encapsulating the ocelot_apply_bridge_fwd_mask() call that
      felix used to have.
      
      This is necessary because the CPU port change procedure will also need
      to do this, and it's good to reduce code duplication by having an entry
      point in the ocelot switch lib that does all that is needed.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a72e23dd
    • Vladimir Oltean's avatar
      net: dsa: felix: move the updating of PGID_CPU to the ocelot lib · 61be79ba
      Vladimir Oltean authored
      PGID_CPU must be updated every time a port is configured or unconfigured
      as a tag_8021q CPU port. The ocelot switch lib already has a hook for
      that operation, so move the updating of PGID_CPU to those hooks.
      
      These bits are pretty specific to DSA, so normally I would keep them out
      of the common switch lib, but when tag_8021q is in use, this has
      implications upon the forwarding mask determined by
      ocelot_apply_bridge_fwd_mask() and called extensively by the switch lib.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61be79ba
    • Vladimir Oltean's avatar
      net: dsa: fix missing adjustment of host broadcast flooding · 129b7532
      Vladimir Oltean authored
      PGID_BC is configured statically by ocelot_init() to flood towards the
      CPU port module, and dynamically by ocelot_port_set_bcast_flood()
      towards all user ports.
      
      When the tagging protocol changes, the intention is to turn off flooding
      towards the old pipe towards the host, and to turn it on towards the new
      pipe.
      
      Due to a recent change which removed the adjustment of PGID_BC from
      felix_set_host_flood(), 3 things happen.
      
      - when we change from NPI to tag_8021q mode: in this mode, the CPU port
        module is accessed via registers, and used to read PTP packets with
        timestamps. We fail to disable broadcast flooding towards the CPU port
        module, and to enable broadcast flooding towards the physical port
        that serves as a DSA tag_8021q CPU port.
      
      - from tag_8021q to NPI mode: in this mode, the CPU port module is
        redirected to a physical port. We fail to disable broadcast flooding
        towards the physical tag_8021q CPU port, and to enable it towards the
        CPU port module at ocelot->num_phys_ports.
      
      - when the ports are put in promiscuous mode, we also fail to update
        PGID_BC towards the host pipe of the current protocol.
      
      First issue means that felix_check_xtr_pkt() has to do extra work,
      because it will not see only PTP packets, but also broadcasts. It needs
      to dequeue these packets just to drop them.
      
      Third issue is inconsequential, since PGID_BC is allocated from the
      nonreserved multicast PGID space, and these PGIDs are conveniently
      initialized to 0x7f (i.e. flood towards all ports except the CPU port
      module). Broadcasts reach the NPI port via ocelot_init(), and reach the
      tag_8021q CPU port via the hardware defaults.
      
      Second issue is also inconsequential, because we fail both at disabling
      and at enabling broadcast flooding on a port, so the defaults mentioned
      above are preserved, and they are fine except for the performance impact.
      
      Fixes: 7a29d220 ("net: dsa: felix: reimplement tagging protocol change with function pointers")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      129b7532
    • Jakub Kicinski's avatar
      Merge branch 'fix-silence-gcc-12-warnings-in-drivers-net-wireless' · 1e39b27b
      Jakub Kicinski authored
      Jakub Kicinski says:
      
      ====================
      Fix/silence GCC 12 warnings in drivers/net/wireless/
      
      as mentioned off list we'd like to get GCC 12 warnings quashed.
      This set takes care of the warnings we have in drivers/net/wireless/
      mostly by relegating them to W=1/W=2 builds.
      ====================
      
      Link: https://lore.kernel.org/r/20220520194320.2356236-1-kuba@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1e39b27b
    • Jakub Kicinski's avatar
      wifi: carl9170: silence a GCC 12 -Warray-bounds warning · 13182526
      Jakub Kicinski authored
      carl9170 has a big union (struct carl9170_cmd) with all the command
      types in it. But it allocates buffers only large enough for a given
      command. This upsets GCC 12:
      
      drivers/net/wireless/ath/carl9170/cmd.c:125:30: warning: array subscript ‘struct carl9170_cmd[0]’ is partly outside array bounds of ‘unsigned char[8]’ [-Warray-bounds]
        125 |                 tmp->hdr.cmd = cmd;
            |                 ~~~~~~~~~~~~~^~~~~
      
      Punt the warning to W=1 for now. Hopefully GCC will learn to
      recognize which fields are in-bounds.
      Acked-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Acked-by: default avatarKalle Valo <kvalo@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      13182526
    • Jakub Kicinski's avatar
      wifi: brcmfmac: work around a GCC 12 -Warray-bounds warning · 84f23fb1
      Jakub Kicinski authored
      GCC 12 really doesn't like partial struct allocations:
      
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:2202:32: warning: array subscript ‘struct brcmf_ext_join_params_le[0]’ is partly outside array bounds of ‘void[70]’ [-Warray-bounds]
       2202 |                 ext_join_params->scan_le.passive_time =
            |                                ^~
      
      brcmfmac is trying to save 2 bytes at the end by either allocating
      or not allocating a channel member. Let's keep @join_params_size
      the "right" size but kmalloc() the full structure.
      Acked-by: default avatarKalle Valo <kvalo@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      84f23fb1
    • Jakub Kicinski's avatar
      wifi: iwlwifi: use unsigned to silence a GCC 12 warning · af3cdfd3
      Jakub Kicinski authored
      GCC 12 says:
      
      drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1076:37: warning: array subscript -1 is below array bounds of ‘struct iwl_mvm_tid_data[9]’ [-Warray-bounds]
       1076 |                 if (mvmsta->tid_data[tid].state != IWL_AGG_OFF)
            |                     ~~~~~~~~~~~~~~~~^~~~~
      
      Whatever, tid is a bit from for_each_set_bit(), it's clearly unsigned.
      Acked-by: default avatarKalle Valo <kvalo@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      af3cdfd3
    • Jakub Kicinski's avatar
      wifi: ath6k: silence false positive -Wno-dangling-pointer warning on GCC 12 · bd1d129d
      Jakub Kicinski authored
      For some reason GCC 12 decided to complain about the common
      pattern of queuing an object onto a list on the stack in ath6k:
      
          inlined from ‘ath6kl_htc_mbox_tx’ at drivers/net/wireless/ath/ath6kl/htc_mbox.c:1142:3:
      include/linux/list.h:74:19: warning: storing the address of local variable ‘queue’ in ‘*&packet_15(D)->list.prev’ [-Wdangling-pointer=]
         74 |         new->prev = prev;
            |         ~~~~~~~~~~^~~~~~
      
      Move the warning to W=1, hopefully it goes away with a compiler
      update.
      Acked-by: default avatarKalle Valo <kvalo@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bd1d129d
    • Jakub Kicinski's avatar
      wifi: rtlwifi: remove always-true condition pointed out by GCC 12 · ee3db469
      Jakub Kicinski authored
      The .value is a two-dim array, not a pointer.
      
      struct iqk_matrix_regs {
      	bool iqk_done;
              long value[1][IQK_MATRIX_REG_NUM];
      };
      Acked-by: default avatarKalle Valo <kvalo@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ee3db469
    • Jakub Kicinski's avatar
      wifi: ath9k: silence array-bounds warning on GCC 12 · e9503298
      Jakub Kicinski authored
      GCC 12 says:
      
      drivers/net/wireless/ath/ath9k/mac.c: In function ‘ath9k_hw_resettxqueue’:
      drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: array subscript 32 is above array bounds of ‘struct ath9k_tx_queue_info[10]’ [-Warray-bounds]
        373 |         qi = &ah->txq[q];
            |               ~~~~~~~^~~
      
      I don't know where it got the 32 from, relegate the warning to W=1+.
      Acked-by: default avatarKalle Valo <kvalo@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e9503298
    • Jakub Kicinski's avatar
      wifi: plfxlc: remove redundant NULL-check for GCC 12 · 0c7ab953
      Jakub Kicinski authored
      GCC is upset that we check the return value of plfxlc_usb_dev()
      even tho it can't be NULL:
      
      drivers/net/wireless/purelifi/plfxlc/usb.c: In function ‘resume’:
      drivers/net/wireless/purelifi/plfxlc/usb.c:840:20: warning: the comparison will always evaluate as ‘true’ for the address of ‘dev’ will never be NULL [-Waddress]
        840 |         if (!pl || !plfxlc_usb_dev(pl))
            |                    ^
      
      plfxlc_usb_dev() returns an address of one of the members of pl,
      so it's safe to drop these checks.
      Acked-by: default avatarKalle Valo <kvalo@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0c7ab953
  2. 22 May, 2022 26 commits