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.