Re: [PATCH rdma-next v3 07/11] RDMA/efa: Implement functions that submit and complete admin commands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 14, 2019 at 01:45:18PM +0200, Gal Pressman wrote:
> Add admin commands submissions/completions implementation.
>
> Signed-off-by: Gal Pressman <galpress@xxxxxxxxxx>
> Reviewed-by: Steve Wise <swise@xxxxxxxxxxxxxxxxxxxxx>
> ---
>  drivers/infiniband/hw/efa/efa_com.c | 1176 +++++++++++++++++++++++++++++++++++
>  1 file changed, 1176 insertions(+)
>  create mode 100644 drivers/infiniband/hw/efa/efa_com.c
>
> diff --git a/drivers/infiniband/hw/efa/efa_com.c b/drivers/infiniband/hw/efa/efa_com.c
> new file mode 100644
> index 000000000000..9c2a7f27c513
> --- /dev/null
> +++ b/drivers/infiniband/hw/efa/efa_com.c
> @@ -0,0 +1,1176 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause
> +/*
> + * Copyright 2018-2019 Amazon.com, Inc. or its affiliates. All rights reserved.
> + */
> +
> +#include "efa.h"
> +#include "efa_com.h"
> +#include "efa_regs_defs.h"
> +
> +#define ADMIN_CMD_TIMEOUT_US 30000000 /* usecs */
> +
> +#define EFA_REG_READ_TIMEOUT_US 50000 /* usecs */
> +#define EFA_MMIO_READ_INVALID 0xffffffff
> +
> +#define EFA_POLL_INTERVAL_MS 100 /* msecs */
> +
> +#define EFA_ASYNC_QUEUE_DEPTH 16
> +#define EFA_ADMIN_QUEUE_DEPTH 32
> +
> +#define MIN_EFA_VER\
> +	((EFA_ADMIN_API_VERSION_MAJOR << EFA_REGS_VERSION_MAJOR_VERSION_SHIFT) | \
> +	 (EFA_ADMIN_API_VERSION_MINOR & EFA_REGS_VERSION_MINOR_VERSION_MASK))
> +
> +#define EFA_CTRL_MAJOR          0
> +#define EFA_CTRL_MINOR          0
> +#define EFA_CTRL_SUB_MINOR      1
> +
> +#define MIN_EFA_CTRL_VER \
> +	(((EFA_CTRL_MAJOR) << \
> +	(EFA_REGS_CONTROLLER_VERSION_MAJOR_VERSION_SHIFT)) | \
> +	((EFA_CTRL_MINOR) << \
> +	(EFA_REGS_CONTROLLER_VERSION_MINOR_VERSION_SHIFT)) | \
> +	(EFA_CTRL_SUB_MINOR))

<...>

> +/**
> + * efa_com_validate_version - Validate the device parameters
> + * @edev: EFA communication layer struct
> + *
> + * This method validate the device parameters are the same as the saved
> + * parameters in edev.
> + * This method is useful after device reset, to validate the device mac address
> + * and the device offloads are the same as before the reset.

Why? Don't your devices survive device reset?

> + *
> + * @return - 0 on success negative value otherwise.
> + */
> +int efa_com_validate_version(struct efa_com_dev *edev)
> +{
> +	u32 ctrl_ver_masked;
> +	u32 ctrl_ver;
> +	u32 ver;
> +
> +	/*
> +	 * Make sure the EFA version and the controller version are at least
> +	 * as the driver expects
> +	 */
> +	ver = efa_com_reg_read32(edev, EFA_REGS_VERSION_OFF);
> +	ctrl_ver = efa_com_reg_read32(edev,
> +				      EFA_REGS_CONTROLLER_VERSION_OFF);
> +
> +	efa_info(edev->dmadev,
> +		 "efa device version: %d.%d\n",
> +		 (ver & EFA_REGS_VERSION_MAJOR_VERSION_MASK) >>
> +		 EFA_REGS_VERSION_MAJOR_VERSION_SHIFT,
> +		 ver & EFA_REGS_VERSION_MINOR_VERSION_MASK);
> +
> +	if (ver < MIN_EFA_VER) {
> +		efa_err(edev->dmadev,
> +			"EFA version is lower than the minimal version the driver supports\n");
> +		return -EOPNOTSUPP;
> +	}

I don't know maybe it is common practice, but how do you plan to manage
supported/not supported matrix? Usually from the day one, driver works with
all released HW and future features supports with special capabilities
bits.

Thanks

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux