Re: [RFC PATCH v4 10/25] RDMA/irdma: Add driver framework definitions

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Feb 20, 2020 at 10:24:05PM +0000, Parav Pandit wrote:
> 
> 
> > From: Saleem, Shiraz <shiraz.saleem@intel.com>
> > Sent: Tuesday, February 18, 2020 2:43 PM
> > To: Parav Pandit <parav@mellanox.com>; Kirsher, Jeffrey T
> > <jeffrey.t.kirsher@intel.com>; davem@davemloft.net;
> > gregkh@linuxfoundation.org
> > Cc: Ismail, Mustafa <mustafa.ismail@intel.com>; netdev@vger.kernel.org;
> > linux-rdma@vger.kernel.org; nhorman@redhat.com; sassmann@redhat.com;
> > jgg@ziepe.ca
> > Subject: RE: [RFC PATCH v4 10/25] RDMA/irdma: Add driver framework
> > definitions
> > 
> > [..]
> > 
> > > > +static int irdma_devlink_reload_up(struct devlink *devlink,
> > > > +				   struct netlink_ext_ack *extack) {
> > > > +	struct irdma_dl_priv *priv = devlink_priv(devlink);
> > > > +	union devlink_param_value saved_value;
> > > > +	const struct virtbus_dev_id *id = priv->vdev->matched_element;
> > >
> > > Like irdma_probe(), struct iidc_virtbus_object *vo is accesible for the given
> > priv.
> > > Please use struct iidc_virtbus_object for any sharing between two drivers.
> > > matched_element modification inside the virtbus match() function and
> > > accessing pointer to some driver data between two driver through this
> > > matched_element is not appropriate.
> > 
> > We can possibly avoid matched_element and driver data look up here.
> > But fundamentally, at probe time (see irdma_gen_probe) the irdma driver
> > needs to know which generation type of vdev we bound to. i.e. i40e or ice ?
> > since we support both.
> > And based on it, extract the driver specific virtbus device object, i.e
> > i40e_virtbus_device vs iidc_virtbus_object and init that device.
> > 
> > Accessing driver_data off the vdev matched entry in irdma_virtbus_id_table
> > is how we know this generation info and make the decision.
> > 
> If there is single irdma driver for two different virtbus device
> types, it is better to have two instances of
> virtbus_register_driver() with different matching string/id.

Yes, I think this also makes sense

The probe mechanism should include the entry pointer like PCI does for
probe so that the driver knows what to do.

Jason