Luca Coelho [Sun, 31 Jan 2021 18:22:07 +0000 (20:22 +0200)]
iwlwifi: mvm: implement approved list for the PPAG feature
We should only allow PPAG to be enabled by OEMs that are in the
approved list. In order to do this, we need to compare the system
vendor string retrieved from SMBIOS to a list maintained in the
driver. If the vendor string is not in the list, we don't allow PPAG
to be used.
For now the list is empty, but entries will be added to it
individually, in subsequent patches.
Luca Coelho [Sun, 31 Jan 2021 18:22:06 +0000 (20:22 +0200)]
iwlwifi: mvm: set enabled in the PPAG command properly
When version 2 of the PER_PLATFORM_ANT_GAIN_CMD was implemented, we
started copying the values from the command that we have stored into a
local instance. But we accidentally forgot to copy the enabled flag,
so in practice PPAG is never really enabled. Fix this by copying the
flag from our stored data a we should.
We should only collect debug data after exiting suspend state, that's
why we delete the current place in d3.c file, and add it to fwrt flows
that occur while we can still access the fw and collect debug data.
Once the all the stations completed the switch, we need
to clear csa_tx_blocked_vif. This was missing. We also
need to re-enable the broadcast / multicast stations.
iwlwifi: mvm: cancel the scan delayed work when scan is aborted
When we abort the scan because of a firmware crash, we
need to cancel the delayed work that monitors the scan
completion. Otherwise it'll kick and try to restart the
firmware yet another time.
Luca Coelho [Fri, 5 Feb 2021 09:06:38 +0000 (11:06 +0200)]
iwlwifi: pcie: add support for SnJ with Hr1
Add an entry for SnJ with Hr1. This device should use the
tx_with_siso_diversity option, but that doesn't work at the moment.
So we leave it disabled for now (and use the same struct as Hr2).
Luca Coelho [Fri, 5 Feb 2021 09:06:37 +0000 (11:06 +0200)]
iwlwifi: mvm: move early time-point before nvm_init in non-unified
We were starting the early time-point too late in non-unified
firmwares. Unlike with unified firmwares, we were starting it only
after reading the NVM, so errors in the NVM read phase were not
logged.
Solve this by moving the time-point to the same place as we do with
unified firmwares, i.e. just before we go into the wait-alive code.
Luca Coelho [Fri, 5 Feb 2021 09:06:35 +0000 (11:06 +0200)]
iwlwifi: move SnJ and So rules to the new tables
We were hardcoding the SnJ and So IDs already at the trans_cfg
selection, instead of doing it in a more generic way. Use the generic
trans_cfg selection for these devices and move the hardcoded IDs to
the new table.
Johannes Berg [Fri, 5 Feb 2021 09:06:34 +0000 (11:06 +0200)]
iwlwifi: mvm: slightly clean up rs_fw_set_supp_rates()
The "supp" variable doesn't need to be unsigned long, only
"tmp" is used with for_each_set_bit(). "supp" should just
be a u16, since that's how it's sent to the firmware.
Johannes Berg [Fri, 5 Feb 2021 09:06:33 +0000 (11:06 +0200)]
iwlwifi: fw api: make hdr a zero-size array again
In struct iwl_tx_cmd, there's no risk (as Arnd implied) that we
might access this as an array, as it's really not an array and
cannot be - there's only a single 802.11 header per frame. The
only reason for this member is for being able to access it a
bit more nicely.
On the other hand, this structure is used as a sub-struct in a
few places, and then some compilers (e.g. clang with certain
options) complain as you shouldn't have structs with variable-
length fields embedded in other structs.
Johannes Berg [Fri, 5 Feb 2021 09:06:31 +0000 (11:06 +0200)]
iwlwifi: mvm: advertise BIGTK client support if available
If the firmware has support, then advertise it to the stack and
send the key down. Since we re-check the protection in the host
anyway, we don't really need to do anything on RX except that we
should drop frames that the firmware _knows_ are replay errors,
since beacon filtering might otherwise result in replays being
possible.
Johannes Berg [Sun, 17 Jan 2021 14:52:34 +0000 (16:52 +0200)]
iwlwifi: always allow maximum A-MSDU on newer devices
On devices starting from 9000 series, always allow maximum A-MSDU
sizes regardless of the amsdu_size module parameter, which really
hasn't meant that for a long time but just controls the receive
buffer size.
Johannes Berg [Sun, 17 Jan 2021 14:52:33 +0000 (16:52 +0200)]
iwlwifi: mvm: debugfs: check length precisely in inject_packet
When we check the length, we only check that the advertised
data length fits into the data we have, but currently not
that it actually matches correctly.
This should be harmless, but if the first two bytes are zero,
then the iwl_rx_packet_payload_len() ends up negative, and
that might later cause issues if unsigned variables are used,
as this is not something that's normally expected.
Change the validation here to precisely validate the lengths
match, to avoid such issues.
iwlwifi: tx: move handing sync/async host command to trans
Handling host commands in a sync way is not directly related to PCIe
transport, and can serve as common logic for any transport, so move
it to trans layer.
iwlwifi: mvm: add explicit check for non-data frames in get Tx rate
In roaming flows and during reassociation, its possible that data frames
such as EAPOLs for 4 way handshake/ 802.1x authentication are initially set
to higher MCS rate. Though these are pruned down to a lower legacy rate
before sending to the FW, driver also emits a kernel warning - intended for
non-data frames. Add checks to avoid such warnings for data frames, while
also enhancing the debug data printed.
Shaul Triebitz [Sun, 17 Jan 2021 14:52:27 +0000 (16:52 +0200)]
iwlwifi: mvm: csa: do not abort CSA before disconnect
While disconnecting from the AP due to bad channel switch
params (e.g. too long Tx block), do not send the firmware
'CSA abort' before disconnecting. That causes canceling the
immediate quiet and can cause transmitting data before the
disconnection happens.
Haim Dreyfuss [Sun, 17 Jan 2021 14:52:26 +0000 (16:52 +0200)]
iwlwifi: mvm: don't send commands during suspend\resume transition
D3_CONFIG_CMD and D0I3_END_CMD should be the last\first
command upon suspend\resume correspondingly, otherwise,
FW will raise an assert (0x342).
There are firmware notifications that cause the driver to
send a command back to the firmware. If such a notification
is sent to the driver while the the driver prepares the
firmware for D3, operation, what is likely to happen is that
the handling of the notification will try to get the mutex
and will wait unil the driver finished configuring the
firmware for D3. Then the handling notification will get
the mutex and handle the notification which will lead to
the aforementioned ASSERT 342.
To avoid this, we need to prevent any command to be sent to
the firmware between the D3_CONFIG_CMD and the D0I3_END_CMD.
Check this in the utility layer that sends the host commands
and in the transport layer as well.
Flag the D3_CONFIG_CMD and the D0I3_END_CMD commands as
commands that must be sent even if the firmware has already
been configured for D3 operation.
iwlwifi: mvm: don't check system_pm_mode without mutex held
When we want to stop TX'ing because we are suspending, we
have two options: either we check system_pm_mode or we
check the mvm's status that has a bit for the suspend
flow.
The latter is better because test_bit is atomic. Also
add a call to synchronize_net after we set the bit to
make sure that all the new Tx see the bit before we
actually complete the suspend flow.
Johannes Berg [Sun, 17 Jan 2021 11:10:34 +0000 (13:10 +0200)]
iwlwifi: pcie: properly implement NAPI
Instead of pretending to have NAPI and then relying entirely on
interrupts anyway, properly implement NAPI and schedule the poll
when we get an interrupt, re-enabling the interrupt only after
the poll completed.
iwlwifi: mvm: add support for new flush queue response
In the new api all the flush in the FW is done before we
get the response and in the response we only get the updated
read pointer and all queued packets don't get anymore rx_tx
per packet to free the queued packet, so driver needs to free
all queued packets on flushed queue at once after flush response.
If there are frequent CCA delays due to the extension channel
as detected by the firmware, and we're on 2.4 GHz, then handle
this by disconnecting (with a reconnect hint).
When we disconnect, we'll also update our capabilities to use
only 20 MHz on the next connection (if it's on 2.4 GHz) as to
avoid the use of the extension channel that has too much noise.
When restarting firmware with an ongoing scheduled scan, we
don't (and shouldn't) mark it as aborted as mac80211 will be
restarting it, and so no event should go out to userspace.
The appropriate comment regarding this wasn't moved to this
place, so add it.
However, we _do_ need to clean up our internal state, since
mac80211 will restart the scan, and we'll otherwise get to
the WARN_ON() a few lines below for no reason whatsoever.
For testing features where the firmware may send some
notifications it can often be a lot easier to do that
from a test script. Remove most injection limitations
from debugfs to be able to do this.
Johannes Berg [Sun, 17 Jan 2021 11:10:28 +0000 (13:10 +0200)]
iwlwifi: mvm: add notification size checks
We shouldn't trust the firmware with the sizes (or contents)
of notifications, accessing too much data could cause page
faults if the data doesn't fit into the allocated space. This
applies more on older NICs where multiple notifications can
be in a single RX buffer.
Add a general framework for checking a minimum size of any
notification in the RX handlers and use it for most. Some RX
handlers were already checking and I've moved the checks,
some more complex checks I left and made them _NO_SIZE for
the RX handlers.
iwl4965: do not process non-QOS frames on txq->sched_retry path
We have already WARN_ON(!qc) for non-QOS frame on txq->sched_retry path,
but we continue to process, what makes no sense since tid is not
initialized. Non QOS frame should never happen when aggregation
is enabled on queue, so do not process that.
Patch should fix smatch warning:
drivers/net/wireless/intel/iwlegacy/4965-mac.c:2822 il4965_hdl_tx() error: uninitialized symbol 'tid'.
Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210119100621.439134-1-stf_xl@wp.pl
Tony Lindgren [Fri, 15 Jan 2021 06:56:13 +0000 (08:56 +0200)]
wlcore: Fix command execute failure 19 for wl12xx
We can currently get a "command execute failure 19" error on beacon loss
if the signal is weak:
wlcore: Beacon loss detected. roles:0xff
wlcore: Connection loss work (role_id: 0).
...
wlcore: ERROR command execute failure 19
...
WARNING: CPU: 0 PID: 1552 at drivers/net/wireless/ti/wlcore/main.c:803
...
(wl12xx_queue_recovery_work.part.0 [wlcore])
(wl12xx_cmd_role_start_sta [wlcore])
(wl1271_op_bss_info_changed [wlcore])
(ieee80211_prep_connection [mac80211])
Error 19 is defined as CMD_STATUS_WRONG_NESTING from the wlcore firmware,
and seems to mean that the firmware no longer wants to see the quirk
handling for WLCORE_QUIRK_START_STA_FAILS done.
This quirk got added with commit 18eab430700d ("wlcore: workaround
start_sta problem in wl12xx fw"), and it seems that this already got fixed
in the firmware long time ago back in 2012 as wl18xx never had this quirk
in place to start with.
As we no longer even support firmware that early, to me it seems that it's
safe to just drop WLCORE_QUIRK_START_STA_FAILS to fix the error. Looks
like earlier firmware got disabled back in 2013 with commit 0e284c074ef9
("wl12xx: increase minimum singlerole firmware version required").
If it turns out we still need WLCORE_QUIRK_START_STA_FAILS with any
firmware that the driver works with, we can simply revert this patch and
add extra checks for firmware version used.
With this fix wlcore reconnects properly after a beacon loss.
Chin-Yen Lee [Wed, 13 Jan 2021 01:43:42 +0000 (09:43 +0800)]
rtw88: 8723de: adjust the LTR setting
The LTR mechanism enables PCIE Endpoints to report the service latency
requirements and CPU will enter appropriate sleep state to save power
based on the LTR value.
8723de provides two registers to config the LTR, and the original setting
is too short for CPU to ente sleep state. The patch adjust the LTR setting.
rtlwifi: rtl8821ae: fix bool comparison in expressions
There are certain conditional expressions in rtl8821ae, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c,
"if (rtlefuse->autoload_failflag == false)" can be replaced with
"if (!rtlefuse->autoload_failflag)"
Replace all such expressions with the bool variables appropriately
rtlwifi: rtl8192se: fix bool comparison in expressions
There are certain conditional expressions in rtl8192se, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
Replace all such expressions with the bool variables appropriately
rtlwifi: rtl8188ee: fix bool comparison in expressions
There are certain conditional expressions in rtl8188ee, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c,
"if (mac->act_scanning == true)" can be replaced with
"if (mac->act_scanning)"
Replace all such expressions with the bool variables appropriately
rtlwifi: rtl8192c-common: fix bool comparison in expressions
There are certain conditional expressions in rtl8192c-common, where a
boolean variable is compared with true/false, in forms such as
(foo == true) or (false != bar), which does not comply with checkpatch.pl
(CHECK: BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c,
"else if (initialized == false) {" can be replaced with
"else if (!initialized) {"
Replace all such expressions with the bool variables appropriately
rtlwifi: rtl_pci: fix bool comparison in expressions
There are certain conditional expressions in rtl_pci, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
E.g., in drivers/net/wireless/realtek/rtlwifi/ps.c,
"if (find_p2p_ie == true)" can be replaced with "if (find_p2p_ie)"
Replace all such expressions with the bool variables appropriately
"The WL127x firmware supports max of 3 BA sessions. It cannot be increased.
I think the problem here is the peer trying to initiate a 4th BA session
(ADDBA request)."
Luca Pesce [Thu, 24 Dec 2020 10:51:59 +0000 (11:51 +0100)]
brcmfmac: clear EAP/association status bits on linkdown events
This ensure that previous association attempts do not leave stale statuses
on subsequent attempts.
This fixes the WARN_ON(!cr->bss)) from __cfg80211_connect_result() when
connecting to an AP after a previous connection failure (e.g. where EAP fails
due to incorrect psk but association succeeded). In some scenarios, indeed,
brcmf_is_linkup() was reporting a link up event too early due to stale
BRCMF_VIF_STATUS_ASSOC_SUCCESS bit, thus reporting to cfg80211 a connection
result with a zeroed bssid (vif->profile.bssid is still empty), causing the
WARN_ON due to the call to cfg80211_get_bss() with the empty bssid.
Zhi Han [Thu, 17 Dec 2020 16:16:57 +0000 (17:16 +0100)]
mt7601u: check the status of device in calibration
When the usb device being plugged out, before ieee80211 gets to know the
hw being removed, it gets to know that the association status changed,
and thus ask for the device to do the calibration. This causes error as
the hw is absent.
This can be avoid by checking the status of the device before sending
the calibration request to the device.
Zhi Han [Thu, 17 Dec 2020 16:13:02 +0000 (17:13 +0100)]
mt7601u: process URBs in status EPROTO properly
When the usb device being plugged out, before the usb_driver:disconnect
called by e.g workqueue, it is possible that some URBs are still in
processing, and being marked as EPROTO in host controller.
Those URBs should not be scheduled in complete_rx callback function to
get further processing.
As the Marvell PCIE WiFi-Ex driver does not have any code or data
located in initmem, there is no need to annotate the mwifiex_pcie
structure with __refdata. Drop the annotation, to avoid suppressing
future section warnings.
Ching-Te Ku [Tue, 12 Jan 2021 02:11:35 +0000 (10:11 +0800)]
rtw88: coex: set 4 slot TDMA for BT link and WL busy
To protect both of WL/BT performance while BT is under re-link state.
4-slot mode TDMA can make the re-link more sensitive and mitigate the WL
throughput drop.
Vincent Fann [Mon, 28 Dec 2020 08:25:16 +0000 (16:25 +0800)]
rtw88: 8821c: apply CCK PD level which calculates from dynamic mechanism
Hal function must follow the value that calculates from dynamic mechanism.
Force to set new_lvl to 4 damages receiving ability. System will not able
to reconnect to the AP if wifi unexpected disconnecting at this moment.
Chin-Yen Lee [Mon, 28 Dec 2020 08:24:33 +0000 (16:24 +0800)]
rtw88: reduce the log level for failure of tx report
Sometimes driver does not get tx report from firmware because wifi
environment is too noisy to get ack from AP about a TX frame,
or firmware is too busy to report driver in a estimated time.
But the condition will not affect wifi function or throughput.
So we reduce the log level to rtw_debug instead of scary backtrace.
Rafał Miłecki [Wed, 6 Jan 2021 21:32:02 +0000 (22:32 +0100)]
net: dsa: bcm_sf2: support BCM4908's integrated switch
BCM4908 family SoCs come with integrated Starfighter 2 switch. Its
registers layout it a mix of BCM7278 and BCM7445. It has 5 integrated
PHYs and 8 ports. It also supports RGMII and SerDes.
====================
MPTCP: Add MP_PRIO support and rework local address IDs
Patches 1 and 2 rework the assignment of local address IDs to allow them
to be assigned by a userspace path manager, and add corresponding self
tests.
Patches 2-8 add the ability to change subflow priority after a subflow
has been established. Each subflow in a MPTCP connection has a priority
level: "regular" or "backup". Data should only be sent on backup
subflows if no regular subflows are available. The priority level can be
set when the subflow connection is established (as was already
implemented), or during the life of the connection by sending MP_PRIO in
the TCP options (as added here). Self tests are included.
====================
Geliang Tang [Sat, 9 Jan 2021 00:48:02 +0000 (16:48 -0800)]
selftests: mptcp: add the MP_PRIO testcases
This patch added the MP_PRIO testcases:
Add a new argument bkup for run_tests and do_transfer, it can be set as
"backup" or "nobackup", the default value is "".
Add a new function chk_prio_nr to check the MP_PRIO related MIB counters.
The output looks like this:
29 single subflow, backup syn[ ok ] - synack[ ok ] - ack[ ok ]
ptx[ ok ] - prx [ ok ]
30 single address, backup syn[ ok ] - synack[ ok ] - ack[ ok ]
add[ ok ] - echo [ ok ]
ptx[ ok ] - prx [ ok ]
Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Geliang Tang [Sat, 9 Jan 2021 00:48:00 +0000 (16:48 -0800)]
selftests: mptcp: add set_flags command in pm_nl_ctl
This patch added the set_flags command in pm_nl_ctl, currently we can only
set two flags: backup and nobackup. The set_flags command can be used like
this:
# pm_nl_ctl set 10.0.0.1 flags backup
# pm_nl_ctl set 10.0.0.1 flags nobackup
Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Geliang Tang [Sat, 9 Jan 2021 00:47:59 +0000 (16:47 -0800)]
mptcp: add set_flags command in PM netlink
This patch added a new command MPTCP_PM_CMD_SET_FLAGS in PM netlink:
In mptcp_nl_cmd_set_flags, parse the input address, get the backup value
according to whether the address's FLAG_BACKUP flag is set from the
user-space. Then check whether this address had been added in the local
address list. If it had been, then call mptcp_nl_addr_backup to deal with
this address.
In mptcp_nl_addr_backup, traverse all the existing msk sockets to find
the relevant sockets, and call mptcp_pm_nl_mp_prio_send_ack to send out
a MP_PRIO ACK packet.
Finally in mptcp_nl_cmd_set_flags, set or clear the address's FLAG_BACKUP
flag.
Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Geliang Tang [Sat, 9 Jan 2021 00:47:58 +0000 (16:47 -0800)]
mptcp: add the incoming MP_PRIO support
This patch added the incoming MP_PRIO logic:
Added a flag named mp_prio in struct mptcp_options_received, to mark the
MP_PRIO is received, and save the priority value to struct
mptcp_options_received's backup member. Then invoke
mptcp_pm_mp_prio_received with the receiving subsocket and the backup
value.
In mptcp_pm_mp_prio_received, get the subflow context according the input
subsocket, and change the subflow's backup as the incoming priority value.
Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Geliang Tang [Sat, 9 Jan 2021 00:47:57 +0000 (16:47 -0800)]
mptcp: add the outgoing MP_PRIO support
This patch added the outgoing MP_PRIO logic:
In mptcp_pm_nl_mp_prio_send_ack, find the related subflow and subsocket
according to the input parameter addr. Save the input priority value to
suflow's backup, then set subflow's send_mp_prio flag to true, and save
the input priority value to suflow's request_bkup. Finally, send out a
pure ACK on the related subsocket.
In mptcp_established_options_mp_prio, check whether the subflow's
send_mp_prio is set. If it is, this is the packet for sending MP_PRIO.
So save subflow->request_bkup value to mptcp_out_options's backup, and
change the option type to OPTION_MPTCP_PRIO.
In mptcp_write_options, clear the send_mp_prio flag and send out the
MP_PRIO suboption with mptcp_out_options's backup value.
Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Geliang Tang [Sat, 9 Jan 2021 00:47:56 +0000 (16:47 -0800)]
selftests: mptcp: add testcases for setting the address ID
Since the address ID can be set from user-space, some of the tests in
pm_netlink.sh will fail. This patch fixed the failures, and add the
testcases for setting the address ID.
Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Geliang Tang [Sat, 9 Jan 2021 00:47:55 +0000 (16:47 -0800)]
mptcp: add the address ID assignment bitmap
Currently the address ID set by the netlink PM from user-space is
overridden by the kernel. This patch added the address ID assignment
bitmap to allow user-space to set the address ID.
Use a per netns bitmask id_bitmap (256 bits) to keep track of in-use IDs.
And use next_id to keep track of the highest ID currently in use. If the
user-space provides an ID at endpoint creation time, try to use it. If
already in use, endpoint creation fails. Otherwise pick the first ID
available after the highest currently in use, with wrap-around.
Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Fri, 8 Jan 2021 23:30:54 +0000 (01:30 +0200)]
net: dsa: dsa_legacy_fdb_{add,del} can be static
Introduced in commit 37b8da1a3c68 ("net: dsa: Move FDB add/del
implementation inside DSA") in net/dsa/legacy.c, these functions were
moved again to slave.c as part of commit 2a93c1a3651f ("net: dsa: Allow
compiling out legacy support"), before actually deleting net/dsa/slave.c
in 93e86b3bc842 ("net: dsa: Remove legacy probing support"). Along with
that movement there should have been a deletion of the prototypes from
dsa_priv.h, they are not useful.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210108233054.1222278-1-olteanv@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Sun, 10 Jan 2021 00:21:33 +0000 (16:21 -0800)]
Merge branch 'dpaa2-mac-various-updates'
Ioana Ciornei says:
====================
dpaa2-mac: various updates
The first two patches of this series extends the MAC statistics support
to also work for network interfaces which have their link status handled
by firmware (TYPE_FIXED).
The next two patches are fixing a sporadic problem which happens when
the connected DPMAC object is not yet discovered by the fsl-mc bus, thus
the dpaa2-eth is not able to get a reference to it. A referred probe
will be requested in this case.
Finally, the last two patches make some cosmetic changes, mostly
removing comments and unnecessary checks.
Changes in v2:
- replaced IS_ERR_OR_NULL() by IS_ERR() in patch 4/6
- reworded the commit message of patch 6/6
====================
Ioana Ciornei [Fri, 8 Jan 2021 09:07:27 +0000 (11:07 +0200)]
dpaa2-mac: remove a comment regarding pause settings
The MC firmware takes these PAUSE/ASYM_PAUSE flags provided by the
driver, transforms them back into rx/tx pause enablement status and
applies them to hardware. We are not losing information by this
transformation, thus remove the comment.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ioana Ciornei [Fri, 8 Jan 2021 09:07:26 +0000 (11:07 +0200)]
dpaa2-mac: remove an unnecessary check
The dpaa2-eth driver has phylink integration only if the connected dpmac
object is in TYPE_PHY (aka the PCS/PHY etc link status is managed by
Linux instead of the firmware). The check is thus unnecessary because
the code path that reaches the .mac_link_up() callback is only with
TYPE_PHY dpmac objects.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ioana Ciornei [Fri, 8 Jan 2021 09:07:25 +0000 (11:07 +0200)]
dpaa2-eth: retry the probe when the MAC is not yet discovered on the bus
The fsl_mc_get_endpoint() function now returns -EPROBE_DEFER when the
dpmac device was not yet discovered by the fsl-mc bus. When this
happens, pass the error code up so that we can retry the probe at a
later time.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ioana Ciornei [Fri, 8 Jan 2021 09:07:24 +0000 (11:07 +0200)]
bus: fsl-mc: return -EPROBE_DEFER when a device is not yet discovered
The fsl_mc_get_endpoint() should return a pointer to the connected
fsl_mc device, if there is one. By interrogating the MC firmware, we
know if there is an endpoint or not so when the endpoint device is
actually searched on the fsl-mc bus and not found we are hitting the
case in which the device has not been yet discovered by the bus.
Return -EPROBE_DEFER so that callers can differentiate this case.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Acked-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ioana Ciornei [Fri, 8 Jan 2021 09:07:23 +0000 (11:07 +0200)]
dpaa2-mac: export MAC counters even when in TYPE_FIXED
If the network interface object is connected to a MAC of TYPE_FIXED, the
link status management is handled exclusively by the firmware. This does
not mean that the driver cannot access the MAC counters and export them
in ethtool.
For this to happen, we open the attached dpmac device and keep a pointer
to it in priv->mac. Because of this, all the checks in the driver of the
following form 'if (priv->mac)' have to be updated to actually check
the dpmac attribute and not rely on the presence of a non-NULL value.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Ioana Ciornei [Fri, 8 Jan 2021 09:07:22 +0000 (11:07 +0200)]
dpaa2-mac: split up initializing the MAC object from connecting to it
Split up the initialization phase of the dpmac object from actually
configuring the phylink instance, connecting to it and configuring the
MAC. This is done so that even though the dpni object is connected to a
dpmac which has link management handled by the firmware we are still
able to export the MAC counters.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Fri, 8 Jan 2021 11:39:03 +0000 (03:39 -0800)]
net-gro: remove GRO_DROP
GRO_DROP can only be returned from napi_gro_frags()
if the skb has not been allocated by a prior napi_get_frags()
Since drivers must use napi_get_frags() and test its result
before populating the skb with metadata, we can safely remove
GRO_DROP since it offers no practical use.
Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by: Edward Cree <ecree.xilinx@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Sat, 9 Jan 2021 21:51:39 +0000 (13:51 -0800)]
Merge branch 'net-ipa-support-compile_test'
Alex Elder says:
====================
net: ipa: support COMPILE_TEST
This series adds the IPA driver as a possible target when
the COMPILE_TEST configuration is enabled. Two small changes to
dependent subsystems needed to be made for this to work.
Version 2 of this series adds one more patch, which adds the
declation of struct page to "gsi_trans.h". The Intel kernel test
robot reported that this was a problem for the alpha build.
====================
Alex Elder [Thu, 7 Jan 2021 23:34:03 +0000 (17:34 -0600)]
net: ipa: declare the page pointer type in "gsi_trans.h"
The second argument to gsi_trans_page_add() is a page pointer.
That declaration is found in header files used by "gsi_trans.h" for
(at least) arm64 and x86 builds, but apparently not for alpha
builds.
Fix this by adding a declaration of struct page to the top of
"gsi_trans.h".
Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alex Elder [Thu, 7 Jan 2021 23:34:02 +0000 (17:34 -0600)]
soc: qcom: mdt_loader: define stubs for COMPILE_TEST
Define stub functions for the exposed MDT functions in case
QCOM_MDT_LOADER is not configured. This allows users of these
functions to link correctly for COMPILE_TEST builds without
QCOM_SCM enabled.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Alex Elder [Thu, 7 Jan 2021 23:34:01 +0000 (17:34 -0600)]
remoteproc: qcom: expose types for COMPILE_TEST
Stub functions are defined for SSR notifier registration in case
QCOM_RPROC_COMMON is not configured. As a result, code that uses
these functions can link successfully even if the common remoteproc
code is not built.
Code that registers an SSR notifier function likely needs the
types defined in "qcom_rproc.h", but those are only exposed if
QCOM_RPROC_COMMON is enabled.
Rearrange the conditional definition so the qcom_ssr_notify_data
structure and qcom_ssr_notify_type enumerated type are defined
whether or not QCOM_RPROC_COMMON is enabled.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>