Thread (25 messages) 25 messages, 4 authors, 2021-03-25

Re: [PATCH net-next] net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag protocol

From: Tobias Waldekranz <tobias@waldekranz.com>
Date: 2021-03-24 12:54:20

On Wed, Mar 24, 2021 at 01:44, Andrew Lunn [off-list ref] wrote:
quoted
This was my initial approach. It gets quite messy though. Since taggers
can be modules, there is no way of knowing if a supplied protocol name
is garbage ("asdf"), or just part of a module in an initrd that is not
loaded yet when you are probing the tree.
Hi Tobias

I don't think that is an issue. We currently lookup the tagger in
dsa_port_parse_cpu(). If it does not exist, we return
-EPROBE_DEFER. Either it eventually gets loaded, or the driver core
gives up. I don't see why the same cannot be done for a DT
property. If dsa_find_tagger_by_name() does not find the tagger return
-EPROBE_DEFER. Garbage will result in the switch never loading, and
the DT writer will go find their typo.
quoted
Even when the tagger is available, there is no way to verify if the
driver is compatible with it.
I would of though, calling the switch drivers change_tag_protocol() op
will that for you. If it comes back with -EINVAL, or -EOPNOTSUPP, you
know it is not compatible.

So i guess i would keep all the code you are adding here to allow
dynamic setting of the protocol. And add more code in
dsa_switch_parse_of() to parse the optional tagging protocol name,
error out -EPROBE_DEFER if it is not known yet, otherwise store it
away in something like dst->tag_ops_name. And then probably in
dsa_switch_setup(), if dst->tag_ops_name is not NULL, invoke the
dynamic change code to perform the actual change.
Sounds like a plan. I will try it out and get back with a v2. Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help