Re: [PATCH net-next 5/5] net: dsa: Stop accessing ds->dst->cpu_dp in drivers

Florian Fainelli [off-list ref] writes:

On 06/06/2017 11:09 AM, Vivien Didelot wrote:

quoted

Florian Fainelli [off-list ref] writes:

quoted

-	phy_mode = of_get_phy_mode(ds->dst->cpu_dp->dn);
+	phy_mode = of_get_phy_mode(ds->ports[QCA8K_CPU_PORT].dn);

Is it necessary to use QCA8K_CPU_PORT?

quoted

+static inline struct dsa_port *dsa_ds_get_cpu_dp(struct dsa_switch *ds)
+{
+	return &ds->ports[fls(ds->cpu_port_mask) - 1];
+}

Wouldn't it be better to return the CPU port for a given port?
Something like return ds->ports[port].cpu_dp, so that we ease the
introduction of multiple CPU port a bit more?

ds->ports[port].cpu_dp only gets assigned at dsa_slave_create() time,
which is after ops->setup() has been called, hence this helper function
in case you need it earlier (e.g: like mv88e6060).

I see no reason why we cannot assign ds->ports[x].cpu_dp before calling
ops->setup().

Even though it can be changed later, the DSA core can assign a dedicated
CPU port to each ports and only after that, call into drivers ops.

To me the DSA topology (dsa_ports, CPU, etc.) should be determined
before calling into the hardware and exposing slave interfaces to the
user. Otherwise it is confusing. Am I wrong?

Thanks,

        Vivien