Re: [PATCH net-next 0/5] Move devlink_register to be near devlink_reload_enable

On Tue, 10 Aug 2021 16:37:30 +0300 Leon Romanovsky wrote:

This series prepares code to remove devlink_reload_enable/_disable API
and in order to do, we move all devlink_register() calls to be right
before devlink_reload_enable().

The best place for such a call should be right before exiting from
the probe().

This is done because devlink_register() opens devlink netlink to the
users and gives them a venue to issue commands before initialization
is finished.

1. Some drivers were aware of such "functionality" and tried to protect
themselves with extra locks, state machines and devlink_reload_enable().
Let's assume that it worked for them, but I'm personally skeptical about
it.

2. Some drivers copied that pattern, but without locks and state
machines. That protected them from reload flows, but not from any _set_
routines.

3. And all other drivers simply didn't understand the implications of early
devlink_register() and can be seen as "broken".

What are those implications for drivers which don't implement reload?
Depending on which parts of devlink the drivers implement there may well
be nothing to worry about.

Plus devlink instances start out with reload disabled. Could you please
take a step back and explain why these changes are needed.

In this series, we focus on items #1 and #2.

Please share your opinion if I should change ALL other drivers to make
sure that devlink_register() is the last command or leave them in an
as-is state.

Can you please share the output of devlink monitor and ip monitor link
before and after?  The modified drivers will not register ports before
they register the devlink instance itself.