#
73b24e7c |
|
16-Oct-2023 |
Jakub Kicinski <kuba@kernel.org> |
eth: bnxt: fix backward compatibility with older devices Recent FW interface update bumped the size of struct hwrm_func_cfg_input above 128B which is the max some devices support. Probe on Stratus (BCM957452) with FW 20.8.3.11 fails with: bnxt_en ...: Unable to reserve tx rings bnxt_en ...: 2nd rings reservation failed. bnxt_en ...: Not enough rings available. Once probe is fixed other errors pop up: bnxt_en ...: Failed to set async event completion ring. This is because __hwrm_send() rejects requests larger than bp->hwrm_max_ext_req_len with -E2BIG. Since the driver doesn't actually access any of the new fields, yet, trim the length. It should be safe. Similar workaround exists for backing_store_cfg_input. Although that one mins() to a constant of 256, not 128 we'll effectively use here. Michael explains: "the backing store cfg command is supported by relatively newer firmware that will accept 256 bytes at least." To make debugging easier in the future add a warning for oversized requests. Fixes: 754fbf604ff6 ("bnxt_en: Update firmware interface to 1.10.2.171") Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20231016171640.1481493-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
0cf736a1 |
|
03-Nov-2022 |
Vikas Gupta <vikas.gupta@broadcom.com> |
bnxt_en: fix the handling of PCIE-AER Fix the sequence required for PCIE-AER. While slot reset occurs, firmware might not be ready and the driver needs to check for its recovery. We also need to remap the health registers for some chips and clear the resource reservations. The resources will be allocated again during bnxt_io_resume(). Fixes: fb1e6e562b37 ("bnxt_en: Fix AER recovery.") Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
b891106d |
|
20-Feb-2022 |
Michael Chan <michael.chan@broadcom.com> |
bnxt_en: Increase firmware message response DMA wait time When polling for the firmware message response, we first poll for the response message header. Once the valid length is detected in the header, we poll for the valid bit at the end of the message which signals DMA completion. Normally, this poll time for DMA completion is extremely short (0 to a few usec). But on some devices under some rare conditions, it can be up to about 20 msec. Increase this delay to 50 msec and use udelay() for the first 10 usec for the common case, and usleep_range() beyond that. Also, change the error message to include the above delay time when printing the timeout value. Fixes: 3c8c20db769c ("bnxt_en: move HWRM API implementation into separate file") Reviewed-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8c6f36d9 |
|
09-Jan-2022 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: improve firmware timeout messaging While it has always been possible to infer that an HWRM command was abandoned due to an unhealthy firmware status by the shortened timeout reported, this change improves the log messaging to account for this case explicitly. In the interests of further clarity, the firmware status is now also reported in these new messages. v2: Remove inline keyword for hwrm_wait_must_abort() in .c file. Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
bce9a0b7 |
|
09-Jan-2022 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: use firmware provided max timeout for messages Some older devices cannot accommodate the 40 seconds timeout cap for long running commands (such as NVRAM commands) due to hardware limitations. Allow these devices to request more time for these long running commands, but print a warning, since the longer timeout may cause the hung task watchdog to trigger. In the case of a firmware update operation, this is preferable to failing outright. v2: Use bp->hwrm_cmd_max_timeout directly without the constants. Fixes: 881d8353b05e ("bnxt_en: Add an upper bound for all firmware command timeouts.") Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
662c9b22 |
|
09-Jan-2022 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: improve VF error messages when PF is unavailable The current driver design relies on the PF netdev being open in order to intercept the following HWRM commands from a VF: - HWRM_FUNC_VF_CFG - HWRM_CFA_L2_FILTER_ALLOC - HWRM_PORT_PHY_QCFG (only if FW_CAP_LINK_ADMIN is not supported) If the PF is closed, then VFs are subjected to rather inscrutable error messages in response to any configuration requests involving the above command types. Recent firmware distinguishes this problem case from other errors by returning HWRM_ERR_CODE_PF_UNAVAILABLE. In most cases, the appropriate course of action is still to fail, but this can now be accomplished with the aid of more user informative log messages. For L2 filter allocations that are already asynchronous, an automatic retry seems more appropriate. v2: Delete extra newline. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
8fa4219d |
|
09-Jan-2022 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: add dynamic debug support for HWRM messages Add logging of firmware messages. These can be useful for diagnosing issues in the field, but due to their verbosity are only appropriate at a debug message level. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
5240118f |
|
01-Sep-2021 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: fix kernel doc warnings in bnxt_hwrm.c Parameter names in the comments did not match the function arguments. Fixes: 213808170840 ("bnxt_en: add support for HWRM request slices") Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Reported-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210901185315.57137-1-edwin.peer@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
68f684e2 |
|
29-Aug-2021 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: support multiple HWRM commands in flight Add infrastructure to maintain a pending list of HWRM commands awaiting completion and reduce the scope of the hwrm_cmd_lock mutex so that it protects only the request mailbox. The mailbox is free to use for one or more concurrent commands after receiving deferred response events. For uniformity and completeness, use the same pending list for collecting completions for commands that respond via a completion ring. These commands are only used for freeing rings and for IRQ test and we only support one such command in flight. Note deferred responses are also only supported on the main channel. The secondary channel (KONG) does not support deferred responses. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b34695a8 |
|
29-Aug-2021 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: remove legacy HWRM interface There are no longer any callers relying on the old API. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
21380817 |
|
29-Aug-2021 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: add support for HWRM request slices Slices are a mechanism for suballocating DMA mapped regions from the request buffer. Such regions can be used for indirect command data instead of creating new mappings with dma_alloc_coherent(). The advantage of using a slice is that the lifetime of the slice is bound to the request and will be automatically unmapped when the request is consumed. A single external region is also supported. This allows for regions that will not fit inside the spare request buffer space such that the same API can be used consistently even for larger mappings. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ecddc29d |
|
29-Aug-2021 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: add HWRM request assignment API hwrm_req_replace() provides an assignment like operation to replace a managed HWRM request object with data from a pre-built source. This is useful for handling request data provided by higher layer HWRM clients. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
02b9aa10 |
|
29-Aug-2021 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: discard out of sequence HWRM responses During firmware crash recovery, it is possible for firmware to respond to stale HWRM commands that have already timed out. Because response buffers may be reused, any out of sequence responses need to be ignored and only the matching seq_id should be accepted. Also, READ_ONCE should be used for the reads from the DMA buffer to ensure that the necessary loads are scheduled. Reviewed-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f9ff5782 |
|
29-Aug-2021 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: introduce new firmware message API based on DMA pools This change constitutes a major step towards supporting multiple firmware commands in flight by maintaining a separate response buffer for the duration of each request. These firmware commands are also known as Hardware Resource Manager (HWRM) commands. Using separate response buffers requires an API change in order for callers to be able to free the buffer when done. It is impossible to keep the existing APIs unchanged. The existing usage for a simple HWRM message request such as the following: struct input req = {0}; bnxt_hwrm_cmd_hdr_init(bp, &req, REQ_TYPE, -1, -1); rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT); if (rc) /* error */ changes to: struct input *req; rc = hwrm_req_init(bp, req, REQ_TYPE); if (rc) /* error */ rc = hwrm_req_send(bp, req); /* consumes req */ if (rc) /* error */ The key changes are: 1. The req is no longer allocated on the stack. 2. The caller must call hwrm_req_init() to allocate a req buffer and check for a valid buffer. 3. The req buffer is automatically released when hwrm_req_send() returns. 4. If the caller wants to check the firmware response, the caller must call hwrm_req_hold() to take ownership of the response buffer and release it afterwards using hwrm_req_drop(). The caller is no longer required to explicitly hold the hwrm_cmd_lock mutex to read the response. 5. Because the firmware commands and responses all have different sizes, some safeguards are added to the code. This patch maintains legacy API compatibiltiy, implementing the old API in terms of the new. The follow-on patches will convert all callers to use the new APIs. v2: Fix redefined writeq with parisc .config Fix "cast from pointer to integer of different size" warning in hwrm_calc_sentinel() Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3c8c20db |
|
29-Aug-2021 |
Edwin Peer <edwin.peer@broadcom.com> |
bnxt_en: move HWRM API implementation into separate file Move all firmware messaging functions and definitions to new bnxt_hwrm.[ch]. The follow-on patches will make major modifications to these APIs. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|