> 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.
This is very similar to what platform_get_device_id does for platform drivers.
https://elixir.bootlin.com/linux/v5.6-rc2/source/drivers/clk/clk-s2mps11.c
Shiraz
