[PATCH net-next v2 7/8] net: stmmac: xgmac: Complete FPE support
Furong Xu
0x1207 at gmail.com
Fri Oct 18 03:00:23 PDT 2024
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.
More information about the linux-arm-kernel
mailing list