On Wed, 1 Feb 2023 10:07:33 +0100 Jiri Pirko wrote: > >This is due to the recommended/required devlink lock/unlock during > >driver initialization/removal. > > > >I think it is better to keep the lock/unlock inside the specific driver > >devlink code, and the functions naming reflects a time window when > >devlink related/dependent processing is being done. > > > >I'm not against changing this, maybe adding the lock/unlock suffix would > >be preferable?: > > > >int efx_probe_devlink_and_lock(struct efx_nic *efx); > >void efx_probe_devlink_unlock(struct efx_nic *efx); > >void efx_fini_devlink_lock(struct efx_nic *efx); > >void efx_fini_devlink_and_unlock(struct efx_nic *efx); > > Sounds better. Thanks! FWIW I'd just take the devl lock in the main driver code. devlink should be viewed as a layer between bus and driver rather than as another subsystem the driver registers with. Otherwise reloads and port creation get awkward. But the above sounds okay, too.
