Hi netdev folks,

there are currently 2 competing implementations for the groundworks to
support standalone PCS drivers.

https://patchwork.kernel.org/project/netdevbpf/list/?series=970582&state=%2A&archive=both

https://patchwork.kernel.org/project/netdevbpf/list/?series=961784&state=%2A&archive=both

They both kinda stalled due to a lack of feedback in the past 2 months
since they have been published.

Merging the 2 implementation is not a viable option due to rather large
architecture differences:

				| Sean			| Ansuel
--------------------------------+-----------------------+-----------------------
Architecture			| Standalone subsystem	| Built into phylink
Need OPs wrapped		| Yes			| No
resource lifecycle		| New subsystem		| phylink
Supports hot remove		| Yes			| Yes
Supports hot add		| Yes (*)		| Yes
provides generic select_pcs	| No			| Yes
support for #pcs-cell-cells	| No			| Yes
allows migrating legacy drivers	| Yes			| Yes
comes with tested migrations	| Yes			| No

(*) requires MAC driver to also unload and subsequent re-probe for link
to work again

Obviously both architectures have pros and cons, here an incomplete and
certainly biased list (please help completing it and discussing all
details):

Standalone Subsystem (Sean)

pros
====
 * phylink code (mostly) untouched
 * doesn't burden systems which don't use dedicated PCS drivers
 * series provides tested migrations for all Ethernet drivers currently
   using dedicated PCS drivers

cons
====
 * needs wrapper for each PCS OP
 * more complex resource management (malloc/free) 
 * hot add and PCS showing up late (eg. due to deferred probe) are
   problematic
 * phylink is anyway the only user of that new subsystem


phylink-managed standalone PCS drivers (Ansuel)

pros
====
 * trivial resource management
 * no wrappers needed
 * full support for hot-add and deferred probe
 * avoids code duplication by providing generic select_pcs
   implementation
 * supports devices which provide more than one PCS port per device
   ('#pcs-cell-cells')

cons
====
 * inclusion in phylink means more (dead) code on platforms not using
   dedicated PCS
 * series does not provide migrations for existing drivers
   (but that can be done after)
 * probably a bit harder to review as one needs to know phylink very well


It would be great if more people can take a look and help deciding the
general direction to go. There are many drivers awaiting merge which
require such infrastructure (most are fine with either of the two), some
for more than a year by now.


Thank you!


Daniel