search for: mlx5_core_dev

From: Leon Romanovsky <leonro at nvidia.com> Changelog: v1: * Renamed _mlx5_rescan_driver to be mlx5_rescan_driver_locked like in other parts of the mlx5 driver. * Renamed MLX5_INTERFACE_PROTOCOL_VDPA to tbe MLX5_INTERFACE_PROTOCOL_VNET as a preparation to coming series from Eli C. * Some small naming renames in mlx5_vdpa. * Refactored adev index code to make Parav's SF series

...> index d25a56ec6876..bcff18a87bcd 100644 > > --- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c > > @@ -40,9 +40,7 @@ void mlx5e_ethtool_get_drvinfo(struct mlx5e_priv > > *priv, { > > struct mlx5_core_dev *mdev = priv->mdev; > > > > - strlcpy(drvinfo->driver, DRIVER_NAME, sizeof(drvinfo->driver)); > > - strlcpy(drvinfo->version, DRIVER_VERSION, > > - sizeof(drvinfo->version)); > > + strlcpy(drvinfo->driver, KBUILD_MODNAME, sizeof(drvinfo- > > &g...

...t; --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c > >> +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c > >> @@ -2322,10 +2322,115 @@ static void update_cvq_info(struct mlx5_vdpa_dev *mvdev) > >> } > >> } > >> > >> +static u8 query_vport_state(struct mlx5_core_dev *mdev, u8 opmod, u16 vport) > >> +{ > >> + u32 out[MLX5_ST_SZ_DW(query_vport_state_out)] = {}; > >> + u32 in[MLX5_ST_SZ_DW(query_vport_state_in)] = {}; > >> + int err; > >> + > >> + MLX5_SET(query_vport_state_in, in, opco...

...ruct mlx5_vdpa_net *ndev, u16 idx) mlx5_db_free(ndev->mvdev.mdev, &vcq->db); } +static int read_umem_params(struct mlx5_vdpa_net *ndev) +{ + u32 in[MLX5_ST_SZ_DW(query_hca_cap_in)] = {}; + u16 opmod = (MLX5_CAP_VDPA_EMULATION << 1) | (HCA_CAP_OPMOD_GET_CUR & 0x01); + struct mlx5_core_dev *mdev = ndev->mvdev.mdev; + int out_size; + void *caps; + void *out; + int err; + + out_size = MLX5_ST_SZ_BYTES(query_hca_cap_out); + out = kzalloc(out_size, GFP_KERNEL); + if (!out) + return -ENOMEM; + + MLX5_SET(query_hca_cap_in, in, opcode, MLX5_CMD_OP_QUERY_HCA_CAP); + MLX5_SET(query_hca_ca...

...} > } > > +static bool f_status_was_set(u64 old, u64 new) > +{ > + if (!(old & BIT_ULL(VIRTIO_NET_F_STATUS)) && > + (new & BIT_ULL(VIRTIO_NET_F_STATUS))) > + return true; > + > + return false; > +} > + > +static u8 query_vport_state(struct mlx5_core_dev *mdev, u8 opmod, u16 vport) > +{ > + u32 out[MLX5_ST_SZ_DW(query_vport_state_out)] = {}; > + u32 in[MLX5_ST_SZ_DW(query_vport_state_in)] = {}; > + int err; > + > + MLX5_SET(query_vport_state_in, in, opcode, MLX5_CMD_OP_QUERY_VPORT_STATE); > + MLX5_SET(query_vport_state_in, in,...

...ernel style, but it's really not: $ git grep -how "struct [A-Za-z0-9_]\+ \*dev" | sort | uniq -c | sort -rn | head -20 38494 struct device *dev 16388 struct net_device *dev 4184 struct drm_device *dev 2780 struct pci_dev *dev 1916 struct comedi_device *dev 1510 struct mlx5_core_dev *dev 1057 struct mlx4_dev *dev 894 struct b43_wldev *dev 762 struct input_dev *dev 623 struct usbnet *dev 561 struct mlx5_ib_dev *dev 525 struct mt76_dev *dev 465 struct mt76x02_dev *dev 435 struct platform_device *dev 431 struct usb_device *dev 411 struct mt7...

...ernel style, but it's really not: $ git grep -how "struct [A-Za-z0-9_]\+ \*dev" | sort | uniq -c | sort -rn | head -20 38494 struct device *dev 16388 struct net_device *dev 4184 struct drm_device *dev 2780 struct pci_dev *dev 1916 struct comedi_device *dev 1510 struct mlx5_core_dev *dev 1057 struct mlx4_dev *dev 894 struct b43_wldev *dev 762 struct input_dev *dev 623 struct usbnet *dev 561 struct mlx5_ib_dev *dev 525 struct mt76_dev *dev 465 struct mt76x02_dev *dev 435 struct platform_device *dev 431 struct usb_device *dev 411 struct mt7...

..._vdpa_ifc.h" > +#include "mlx5_vnet.h" > + > +MODULE_AUTHOR("Eli Cohen <eli at mellanox.com>"); > +MODULE_DESCRIPTION("Mellanox VDPA driver"); > +MODULE_LICENSE("Dual BSD/GPL"); > + > +static bool required_caps_supported(struct mlx5_core_dev *mdev) > +{ > + u8 event_mode; > + u64 got; > + > + got = MLX5_CAP_GEN_64(mdev, general_obj_types); > + > + if (!(got & MLX5_GENERAL_OBJ_TYPES_CAP_VIRTIO_NET_Q)) > + return false; > + > + event_mode = MLX5_CAP_DEV_VDPA_EMULATION(mdev, event_mode); > + if (!(eve...

..._device *vdev, u64 features) return err; ndev->mvdev.actual_features = features & ndev->mvdev.mlx_features; + ndev->config.mtu = __cpu_to_virtio16(mlx5_vdpa_is_little_endian(mvdev), + ndev->mtu); return err; } @@ -1925,7 +1935,7 @@ void *mlx5_vdpa_add_dev(struct mlx5_core_dev *mdev) init_mvqs(ndev); mutex_init(&ndev->reslock); config = &ndev->config; - err = mlx5_query_nic_vport_mtu(mdev, &config->mtu); + err = mlx5_query_nic_vport_mtu(mdev, &ndev->mtu); if (err) goto err_mtu; -- MST

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

This patchset is pre-requisite to export and provision device config attributes and features for vdpa live migration, in a way backward and forward compatibility can be retained. The follow up work [1] will need to be built around the new feature provisioning uAPI, with which it's easier to formalize migration compatibility support at the driver level. Thanks, -Siwei [1] [PATCH v3 0/4] vDPA:

On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. > > I think there is a big benefit when these are all renamed to

On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. > > I think there is a big benefit when these are all renamed to

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is

Hi All: This series tries to add the support for control virtqueue in vDPA. Control virtqueue is used by networking device for accepting various commands from the driver. It's a must to support multiqueue and other configurations. When used by vhost-vDPA bus driver for VM, the control virtqueue should be shadowed via userspace VMM (Qemu) instead of being assigned directly to Guest. This is