linux-dev/drivers/net/ipa/gsi.c, branch linus/master

net: ipa: rename a GSI error code

2022-05-20T10:12:23Z

The CHANNEL_NOT_RUNNING error condition has been generalized, so rename it to be INCORRECT_CHANNEL_STATE. Signed-off-by: Alex Elder Signed-off-by: David S. Miller

net: ipa: drop an unneeded transaction reference

2022-05-20T10:12:23Z

In gsi_channel_update(), a reference count is taken on the last completed transaction "to keep it from completing" before we give the event back to the hardware. Completion processing for that transaction (and any other "new" ones) will not occur until after this function returns, so there's no risk it completing early. So there's no need to take and drop the additional transaction reference. Use local variables in the call to gsi_evt_ring_doorbell(). Signed-off-by: Alex Elder Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2022-05-19T18:23:59Z

drivers/net/ethernet/mellanox/mlx5/core/main.c b33886971dbc ("net/mlx5: Initialize flow steering during driver probe") 40379a0084c2 ("net/mlx5_fpga: Drop INNOVA TLS support") f2b41b32cde8 ("net/mlx5: Remove ipsec_ops function table") https://lore.kernel.org/all/20220519040345.6yrjromcdistu7vh@sx1/ 16d42d313350 ("net/mlx5: Drain fw_reset when removing device") 8324a02c342a ("net/mlx5: Add exit route when waiting for FW") https://lore.kernel.org/all/20220519114119.060ce014@canb.auug.org.au/ tools/testing/selftests/net/mptcp/mptcp_join.sh e274f7154008 ("selftests: mptcp: add subflow limits test-cases") b6e074e171bc ("selftests: mptcp: add infinite map testcase") 5ac1d2d63451 ("selftests: mptcp: Add tests for userspace PM type") https://lore.kernel.org/all/20220516111918.366d747f@canb.auug.org.au/ net/mptcp/options.c ba2c89e0ea74 ("mptcp: fix checksum byte order") 1e39e5a32ad7 ("mptcp: infinite mapping sending") ea66758c1795 ("tcp: allow MPTCP to update the announced window") https://lore.kernel.org/all/20220519115146.751c3a37@canb.auug.org.au/ net/mptcp/pm.c 95d686517884 ("mptcp: fix subflow accounting on close") 4d25247d3ae4 ("mptcp: bypass in-kernel PM restrictions for non-kernel PMs") https://lore.kernel.org/all/20220516111435.72f35dca@canb.auug.org.au/ net/mptcp/subflow.c ae66fb2ba6c3 ("mptcp: Do TCP fallback on early DSS checksum failure") 0348c690ed37 ("mptcp: add the fallback check") f8d4bcacff3b ("mptcp: infinite mapping receiving") https://lore.kernel.org/all/20220519115837.380bb8d4@canb.auug.org.au/ Signed-off-by: Jakub Kicinski

net: ipa: record proper RX transaction count

2022-05-13T11:01:42Z

Each time we are notified that some number of transactions on an RX channel has completed, we record the number of bytes that have been transferred since the previous notification. We also track the number of transactions completed, but that is not currently being calculated correctly; we're currently counting the number of such notifications, but each notification can represent many transaction completions. Fix this. Fixes: 650d1603825d8 ("soc: qcom: ipa: the generic software interface") Signed-off-by: Alex Elder Signed-off-by: David S. Miller

net: switch to netif_napi_add_tx()

2022-05-05T22:54:12Z

Switch net callers to the new API not requiring the NAPI_POLL_WEIGHT argument. Acked-by: Florian Fainelli Reviewed-by: Alex Elder Acked-by: Mat Martineau Acked-by: Alexandra Winter Link: https://lore.kernel.org/r/20220504163725.550782-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

net: ipa: support enhanced channel flow control

2021-11-26T04:04:52Z

IPA v4.2 introduced GSI channel flow control, used instead of IPA endpoint DELAY mode to prevent a TX channel from injecting packets into the IPA core. It used a new FLOW_CONTROLLED channel state which could be entered using GSI generic commands. IPA v4.11 extended the channel flow control model. Rather than having a distinct FLOW_CONTROLLED channel state, each channel has a "flow control" property that can be enabled or not--independent of the channel state. The AP (or modem) can modify this property using the same GSI generic commands as before. The AP only uses channel flow control on modem TX channels, and only when recovering from a modem crash. The AP has no way to discover the state of a modem channel, so the fact that (starting with IPA v4.11) flow control no longer uses a distinct channel state is invisible to the AP. So enhanced flow control generally does not change the way AP uses flow control. There are a few small differences, however: - There is a notion of "primary" or "secondary" flow control, and when enabling or disabling flow control that must be specified in a new field in the GSI generic command register. For now, we always specify 0 (meaning "primary"). - When disabling flow control, it's possible a request will need to be retried. We retry up to 5 times in this case. - Another new generic command allows the current flow control state to be queried. We do not use this. Other than the need for retries, the code essentially works the same way as before. Signed-off-by: Alex Elder Signed-off-by: Jakub Kicinski

net: ipa: introduce channel flow control

2021-11-26T04:03:20Z

One quirk for certain versions of IPA is that endpoint DELAY mode does not work properly. IPA DELAY mode prevents any packets from being delivered to the IPA core for processing on a TX endpoint. The AP uses DELAY mode when the modem crashes, to prevent modem TX endpoints from generating traffic during crash recovery. Without this, there is a chance the hardware will stall during recovery from a modem crash. To achieve a similar effect, a GSI FLOW_CONTROLLED channel state was created. A STARTED TX channel can be placed in FLOW_CONTROLLED state, which prevents the transfer of any more packets. A channel in FLOW_CONTROLLED state can be either returned to STARTED state, or can be transitioned to STOPPED state. Because this operates on GSI channels, two generic commands were added to allow the AP to control this state for modem channels (similar to the ALLOCATE and HALT channel commands). Previously the code assumed this quirk only applied to IPA v4.2. In fact, channel flow control (rather than endpoint DELAY mode) should be used for all versions *starting* with IPA v4.2. Signed-off-by: Alex Elder Signed-off-by: Jakub Kicinski

net: ipa: GSI only needs one completion

2021-11-26T03:37:34Z

A mutex ensures we never submit more than one GSI command of any kind at once. This means the per-channel and per-event ring completion structures provide no benefit. Instead, just use the single (existing) GSI completion to signal the completion of GSI commands of all types. This makes gsi_evt_ring_init() a trivial function with no inverse, so open-code it in its sole caller and get rid of the function. Signed-off-by: Alex Elder Signed-off-by: Jakub Kicinski

net: ipa: disable GSI interrupts while suspended

2021-08-04T09:12:05Z

Introduce new functions gsi_suspend() and gsi_resume(), which will disable the GSI interrupt handler after all endpoints are suspended and re-enable it before endpoints are resumed. This will ensure no GSI interrupt handler will fire when the hardware is suspended. Here's a little further explanation. There are seven GSI interrupt types, and most are disabled except when needed. - These two are not used (never enabled): GSI_INTER_EE_CH_CTRL GSI_INTER_EE_EV_CTRL - These two are only used to implement channel and event ring commands, and are only enabled while a command is underway: GSI_CH_CTRL GSI_EV_CTRL - The IEOB interrupt signals I/O completion. It will not fire when a channel is stopped (or "suspended"). GSI_IEOB - This interrupt is used to allocate or halt modem channels, and is only enabled while such a command is underway. GSI_GLOB_EE However it also is used to signal certain errors, and this could occur at any time. - The general interrupt signals general errors, and could occur at any time. GSI_GENERAL The purpose for this change is to ensure no global or general interrupts fire due to errors while the hardware is suspended. We enable the clock on resume, and at that time we can "handle" (at least report) these error conditions. Signed-off-by: Alex Elder Signed-off-by: David S. Miller

net: ipa: move gsi_irq_init() code into setup

2021-08-04T09:12:05Z

The GSI IRQ handler could be triggered as soon as it is registered with request_irq(). The handler function, gsi_isr(), touches hardware, meaning the IPA clock must be operational. The IPA clock is not operating when the handler is registered (in gsi_irq_init()), so this is a problem. Move the call to request_irq() for the GSI interrupt handler into gsi_irq_setup(), which is called when the IPA clock is known to be operational (and furthermore, the GSI firmware will have been loaded). Request the IRQ at the end of that function, after all interrupt types have been disabled and masked. Move the matching free_irq() call into gsi_irq_teardown(), and get rid of the now empty gsi_irq_exit(), Signed-off-by: Alex Elder Signed-off-by: David S. Miller