/* Broadcom NetXtreme-C/E network driver. * * Copyright (c) 2020 Broadcom Limited * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation. */ #include <asm/byteorder.h> #include <linux/dma-mapping.h> #include <linux/dmapool.h> #include <linux/errno.h> #include <linux/ethtool.h> #include <linux/if_ether.h> #include <linux/io.h> #include <linux/irq.h> #include <linux/kernel.h> #include <linux/list.h> #include <linux/netdevice.h> #include <linux/pci.h> #include <linux/skbuff.h> #include "bnxt_hsi.h" #include "bnxt.h" #include "bnxt_hwrm.h" static u64 hwrm_calc_sentinel(struct bnxt_hwrm_ctx *ctx, u16 req_type) { … } /** * __hwrm_req_init() - Initialize an HWRM request. * @bp: The driver context. * @req: A pointer to the request pointer to initialize. * @req_type: The request type. This will be converted to the little endian * before being written to the req_type field of the returned request. * @req_len: The length of the request to be allocated. * * Allocate DMA resources and initialize a new HWRM request object of the * given type. The response address field in the request is configured with * the DMA bus address that has been mapped for the response and the passed * request is pointed to kernel virtual memory mapped for the request (such * that short_input indirection can be accomplished without copying). The * request’s target and completion ring are initialized to default values and * can be overridden by writing to the returned request object directly. * * The initialized request can be further customized by writing to its fields * directly, taking care to covert such fields to little endian. The request * object will be consumed (and all its associated resources release) upon * passing it to hwrm_req_send() unless ownership of the request has been * claimed by the caller via a call to hwrm_req_hold(). If the request is not * consumed, either because it is never sent or because ownership has been * claimed, then it must be released by a call to hwrm_req_drop(). * * Return: zero on success, negative error code otherwise: * E2BIG: the type of request pointer is too large to fit. * ENOMEM: an allocation failure occurred. */ int __hwrm_req_init(struct bnxt *bp, void **req, u16 req_type, u32 req_len) { … } static struct bnxt_hwrm_ctx *__hwrm_ctx(struct bnxt *bp, u8 *req_addr) { … } /** * hwrm_req_timeout() - Set the completion timeout for the request. * @bp: The driver context. * @req: The request to set the timeout. * @timeout: The timeout in milliseconds. * * Set the timeout associated with the request for subsequent calls to * hwrm_req_send(). Some requests are long running and require a different * timeout than the default. */ void hwrm_req_timeout(struct bnxt *bp, void *req, unsigned int timeout) { … } /** * hwrm_req_alloc_flags() - Sets GFP allocation flags for slices. * @bp: The driver context. * @req: The request for which calls to hwrm_req_dma_slice() will have altered * allocation flags. * @gfp: A bitmask of GFP flags. These flags are passed to dma_alloc_coherent() * whenever it is used to allocate backing memory for slices. Note that * calls to hwrm_req_dma_slice() will not always result in new allocations, * however, memory suballocated from the request buffer is already * __GFP_ZERO. * * Sets the GFP allocation flags associated with the request for subsequent * calls to hwrm_req_dma_slice(). This can be useful for specifying __GFP_ZERO * for slice allocations. */ void hwrm_req_alloc_flags(struct bnxt *bp, void *req, gfp_t gfp) { … } /** * hwrm_req_replace() - Replace request data. * @bp: The driver context. * @req: The request to modify. A call to hwrm_req_replace() is conceptually * an assignment of new_req to req. Subsequent calls to HWRM API functions, * such as hwrm_req_send(), should thus use req and not new_req (in fact, * calls to HWRM API functions will fail if non-managed request objects * are passed). * @len: The length of new_req. * @new_req: The pre-built request to copy or reference. * * Replaces the request data in req with that of new_req. This is useful in * scenarios where a request object has already been constructed by a third * party prior to creating a resource managed request using hwrm_req_init(). * Depending on the length, hwrm_req_replace() will either copy the new * request data into the DMA memory allocated for req, or it will simply * reference the new request and use it in lieu of req during subsequent * calls to hwrm_req_send(). The resource management is associated with * req and is independent of and does not apply to new_req. The caller must * ensure that the lifetime of new_req is least as long as req. Any slices * that may have been associated with the original request are released. * * Return: zero on success, negative error code otherwise: * E2BIG: Request is too large. * EINVAL: Invalid request to modify. */ int hwrm_req_replace(struct bnxt *bp, void *req, void *new_req, u32 len) { … } /** * hwrm_req_flags() - Set non internal flags of the ctx * @bp: The driver context. * @req: The request containing the HWRM command * @flags: ctx flags that don't have BNXT_HWRM_INTERNAL_FLAG set * * ctx flags can be used by the callers to instruct how the subsequent * hwrm_req_send() should behave. Example: callers can use hwrm_req_flags * with BNXT_HWRM_CTX_SILENT to omit kernel prints of errors of hwrm_req_send() * or with BNXT_HWRM_FULL_WAIT enforce hwrm_req_send() to wait for full timeout * even if FW is not responding. * This generic function can be used to set any flag that is not an internal flag * of the HWRM module. */ void hwrm_req_flags(struct bnxt *bp, void *req, enum bnxt_hwrm_ctx_flags flags) { … } /** * hwrm_req_hold() - Claim ownership of the request's resources. * @bp: The driver context. * @req: A pointer to the request to own. The request will no longer be * consumed by calls to hwrm_req_send(). * * Take ownership of the request. Ownership places responsibility on the * caller to free the resources associated with the request via a call to * hwrm_req_drop(). The caller taking ownership implies that a subsequent * call to hwrm_req_send() will not consume the request (ie. sending will * not free the associated resources if the request is owned by the caller). * Taking ownership returns a reference to the response. Retaining and * accessing the response data is the most common reason to take ownership * of the request. Ownership can also be acquired in order to reuse the same * request object across multiple invocations of hwrm_req_send(). * * Return: A pointer to the response object. * * The resources associated with the response will remain available to the * caller until ownership of the request is relinquished via a call to * hwrm_req_drop(). It is not possible for hwrm_req_hold() to return NULL if * a valid request is provided. A returned NULL value would imply a driver * bug and the implementation will complain loudly in the logs to aid in * detection. It should not be necessary to check the result for NULL. */ void *hwrm_req_hold(struct bnxt *bp, void *req) { … } static void __hwrm_ctx_drop(struct bnxt *bp, struct bnxt_hwrm_ctx *ctx) { … } /** * hwrm_req_drop() - Release all resources associated with the request. * @bp: The driver context. * @req: The request to consume, releasing the associated resources. The * request object, any slices, and its associated response are no * longer valid. * * It is legal to call hwrm_req_drop() on an unowned request, provided it * has not already been consumed by hwrm_req_send() (for example, to release * an aborted request). A given request should not be dropped more than once, * nor should it be dropped after having been consumed by hwrm_req_send(). To * do so is an error (the context will not be found and a stack trace will be * rendered in the kernel log). */ void hwrm_req_drop(struct bnxt *bp, void *req) { … } static int __hwrm_to_stderr(u32 hwrm_err) { … } static struct bnxt_hwrm_wait_token * __hwrm_acquire_token(struct bnxt *bp, enum bnxt_hwrm_chnl dst) { … } static void __hwrm_release_token(struct bnxt *bp, struct bnxt_hwrm_wait_token *token) { … } void hwrm_update_token(struct bnxt *bp, u16 seq_id, enum bnxt_hwrm_wait_state state) { … } static void hwrm_req_dbg(struct bnxt *bp, struct input *req) { … } #define hwrm_err(bp, ctx, fmt, ...) … static bool hwrm_wait_must_abort(struct bnxt *bp, u32 req_type, u32 *fw_status) { … } static int __hwrm_send(struct bnxt *bp, struct bnxt_hwrm_ctx *ctx) { … } /** * hwrm_req_send() - Execute an HWRM command. * @bp: The driver context. * @req: A pointer to the request to send. The DMA resources associated with * the request will be released (ie. the request will be consumed) unless * ownership of the request has been assumed by the caller via a call to * hwrm_req_hold(). * * Send an HWRM request to the device and wait for a response. The request is * consumed if it is not owned by the caller. This function will block until * the request has either completed or times out due to an error. * * Return: A result code. * * The result is zero on success, otherwise the negative error code indicates * one of the following errors: * E2BIG: The request was too large. * EBUSY: The firmware is in a fatal state or the request timed out * EACCESS: HWRM access denied. * ENOSPC: HWRM resource allocation error. * EINVAL: Request parameters are invalid. * ENOMEM: HWRM has no buffers. * EAGAIN: HWRM busy or reset in progress. * EOPNOTSUPP: Invalid request type. * EIO: Any other error. * Error handling is orthogonal to request ownership. An unowned request will * still be consumed on error. If the caller owns the request, then the caller * is responsible for releasing the resources. Otherwise, hwrm_req_send() will * always consume the request. */ int hwrm_req_send(struct bnxt *bp, void *req) { … } /** * hwrm_req_send_silent() - A silent version of hwrm_req_send(). * @bp: The driver context. * @req: The request to send without logging. * * The same as hwrm_req_send(), except that the request is silenced using * hwrm_req_silence() prior the call. This version of the function is * provided solely to preserve the legacy API’s flavor for this functionality. * * Return: A result code, see hwrm_req_send(). */ int hwrm_req_send_silent(struct bnxt *bp, void *req) { … } /** * hwrm_req_dma_slice() - Allocate a slice of DMA mapped memory. * @bp: The driver context. * @req: The request for which indirect data will be associated. * @size: The size of the allocation. * @dma_handle: The bus address associated with the allocation. The HWRM API has * no knowledge about the type of the request and so cannot infer how the * caller intends to use the indirect data. Thus, the caller is * responsible for configuring the request object appropriately to * point to the associated indirect memory. Note, DMA handle has the * same definition as it does in dma_alloc_coherent(), the caller is * responsible for endian conversions via cpu_to_le64() before assigning * this address. * * Allocates DMA mapped memory for indirect data related to a request. The * lifetime of the DMA resources will be bound to that of the request (ie. * they will be automatically released when the request is either consumed by * hwrm_req_send() or dropped by hwrm_req_drop()). Small allocations are * efficiently suballocated out of the request buffer space, hence the name * slice, while larger requests are satisfied via an underlying call to * dma_alloc_coherent(). Multiple suballocations are supported, however, only * one externally mapped region is. * * Return: The kernel virtual address of the DMA mapping. */ void * hwrm_req_dma_slice(struct bnxt *bp, void *req, u32 size, dma_addr_t *dma_handle) { … }
Codebase Browser
linux