[PATCH net-next v2 7/8] net: stmmac: xgmac: Complete FPE support

[Furong Xu]

On Fri, 18 Oct 2024 12:13:21 +0300, Vladimir Oltean <olteanv at gmail.com> wrote:

> This is much better in terms of visibility into the change.
> 
> Though I cannot stop thinking that this implementation design:
> 
> stmmac_fpe_configure()
> -> stmmac_do_void_callback()
>    -> fpe_ops->fpe_configure()  
>       /                    \
>      /                      \
>     v                        v
> dwmac5_fpe_configure   dwxgmac3_fpe_configure
>      \                      /
>       \                    /
>        v                  v
>        common_fpe_configure()
> 
> is, pardon the expression, stuffy.
> 
> If you aren't very opposed to the idea of having struct stmmac_fpe_ops
> contain a mix of function pointers and integer constants, I would
> suggest removing:
> 
> 	.fpe_configure()
> 	.fpe_send_mpacket()
> 	.fpe_irq_status()
> 	.fpe_get_add_frag_size()
> 	.fpe_set_add_frag_size()
> 
> and just keeping a single function pointer, .fpe_map_preemption_class(),
> inside stmmac_fpe_ops. Only that is sufficiently different to warrant a
> completely separate implementation. Then move all current struct
> stmmac_fpe_configure_info to struct stmmac_fpe_ops, and reimplement
> stmmac_fpe_configure() directly like common_fpe_configure(),
> stmmac_fpe_send_mpacket() directly like common_fpe_send_mpacket(), etc etc.
> This lets us avoid the antipattern of calling a function pointer (hidden
> by an opaque macro) from common code, only to gather some parameters to
> call again a common implementation.
> 
> I know this is a preposterous and heretic thing to suggest, but a person
> who isn't knee-deep in stmmac has a very hard time locating himself in
> space due to the unnecessarily complex layering. If that isn't something
> that is important, feel free to ignore.

In fact, I can drop the stmmac_fpe_ops at all, avoid the antipattern of
calling a function pointer for good.
Since this is a new module, we can try something new ;)
Thanks.