Re: [PATCH] Revert "arm64: dts: ls1028a: sl28: use ocelot-8021q tagging by default"

From: Michael Walle
Date: Thu Oct 27 2022 - 12:00:15 EST


Am 2022-10-27 14:27, schrieb Vladimir Oltean:

Pretty nasty. Of all the switch drivers that support tagging protocol
change, Ocelot/Felix is the only one with this bug, because in all other
cases, the default and the alternative tagging protocol are part of the
same .ko. Only here we have tag_ocelot.ko and tag_ocelot_8021q.ko.

The problem preventing us from calling request_module() is that currently,
the string identifying the tagging protocol (to which we match device
tree information) is part of the tag_*.ko. I think we'd need the
translation table between string and enum dsa_tag_protocol to be part of
dsa_core.ko.

I think we should treat what we committed to in terms of dt-bindings
with utmost respect, so I would consider your proposed revert as the
absolute last option. Reverting a device tree change doesn't mean that
the device trees without the revert will disappear from circulation.

So far we have 3 options for fixing this within the kernel

- make tag_ocelot.o and tag_ocelot_8021q.o link into the same
tag_ocelot.ko

- change the MODULE_ALIAS() of all tagging protocol driver modules from
"dsa_tag-<number" to something containing their string name - what you
proposed. I don't know why the current MODULE_ALIAS() is formatted the
way it is. Maybe Andrew can comment on whether this is feasible.
I think there isn't any backwards compatibility concern, since only
modules compiled for a certain kernel version are expected to be
loaded.

FWIW, you can have multiple aliases if we somehow need to keep the IDs,
too.

- put a translation table between string and MODULE_ALIAS() inside
dsa_core.ko, which potentially duplicates code. Maybe if we
auto-generate it somehow?

Yeah, I also thought of a table with of name to module alias mapping.
But then you'd have two places to keep in sync (of not autogenerated).

-michael