[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 9 Sep 2021 03:26:01 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Circular dependency between DSA switch driver and tagging
protocol driver
On Wed, Sep 08, 2021 at 03:14:51PM -0700, Florian Fainelli wrote:
> > Where is the problem?
>
> I'd say with 994d2cbb08ca, since the tagger now requires visibility into
> sja1105_switch_ops which is not great, to say the least. You could solve
> this by:
>
> - splitting up the sja1150 between a library that contains
> sja1105_switch_ops and does not contain the driver registration code
I've posted patches which more or less cheat the dependency by creating
a third module, as you suggest. The tagging protocol still depends on
the main module, now sans the call to dsa_register_switch, that is
provided by the third driver, sja1105_probe.ko, which as the name
suggests probes the hardware. The sja1105_probe.ko also depends on
sja1105.ko, so the insmod order needs to be:
insmod sja1105.ko
insmod tag_sja1105.ko
insmod sja1105_probe.ko
I am not really convinced that this change contributes to the overall
code organization and structure.
> - finding a different way to do a dsa_switch_ops pointer comparison, by
> e.g.: maintaining a boolean in dsa_port that tracks whether a particular
> driver is backing that port
Maybe I just don't see how this would scale. So to clarify, are you
suggesting to add a struct dsa_port :: bool is_sja1105, which the
sja1105 driver would set to true in sja1105_setup?
If this was not a driver I would be maintaining, just watching as a
reviewer, I believe "no" is what I would say to that.
Powered by blists - more mailing lists