Florian Fainelli <f.faine...@gmail.com> writes:
> On 06/06/2017 11:09 AM, Vivien Didelot wrote:
>> Florian Fainelli <f.faine...@gmail.com> writes:
>>
>>> - 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?
>>
>>> +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
