Hi Florian,
Florian Fainelli writes:
>> Also I do not think that it is a good thing that a DSA driver play much
>> in dsa_port structures (they are ideally DSA core only specific data).
>> They only seem to need the master interface, so what I see is:
>>
>> static inline struct net_device *
On 06/07/2017 04:24 PM, Vivien Didelot wrote:
> Hi Florian,
>
> Sorry to bother you again, I don't want to be annoying but I might not
> get things right still.
>
> Florian Fainelli writes:
>
> So as I said in v2, now that a driver is guaranteed that dp->cpu_dp is
> correctly assigned a
Hi Florian,
Sorry to bother you again, I don't want to be annoying but I might not
get things right still.
Florian Fainelli writes:
So as I said in v2, now that a driver is guaranteed that dp->cpu_dp is
correctly assigned at setup time, isn't better (especially for future
multi-C
Florian Fainelli writes:
> On 06/07/2017 10:15 AM, Vivien Didelot wrote:
>> Hi Florian,
>>
>> Florian Fainelli writes:
>>
So as I said in v2, now that a driver is guaranteed that dp->cpu_dp is
correctly assigned at setup time, isn't better (especially for future
multi-CPU suppor
On 06/07/2017 10:15 AM, Vivien Didelot wrote:
> Hi Florian,
>
> Florian Fainelli writes:
>
>>> So as I said in v2, now that a driver is guaranteed that dp->cpu_dp is
>>> correctly assigned at setup time, isn't better (especially for future
>>> multi-CPU support) to provide an helper which return
Hi Florian,
Florian Fainelli writes:
>> So as I said in v2, now that a driver is guaranteed that dp->cpu_dp is
>> correctly assigned at setup time, isn't better (especially for future
>> multi-CPU support) to provide an helper which returns the CPU port for a
>> given port? i.e. dsa_get_cpu_port
2017-06-06 19:11 GMT-07:00 Vivien Didelot :
> Hi Florian,
>
> Florian Fainelli writes:
>
>> +static inline struct dsa_port *dsa_ds_get_cpu_dp(struct dsa_switch *ds)
>> +{
>> + return &ds->ports[fls(ds->cpu_port_mask) - 1];
>> +}
>
> So as I said in v2, now that a driver is guaranteed that dp->
Hi Florian,
Florian Fainelli writes:
> +static inline struct dsa_port *dsa_ds_get_cpu_dp(struct dsa_switch *ds)
> +{
> + return &ds->ports[fls(ds->cpu_port_mask) - 1];
> +}
So as I said in v2, now that a driver is guaranteed that dp->cpu_dp is
correctly assigned at setup time, isn't better
Out of the few drivers that do access ds->dst->cpu_dp, there is only a
handful for which we cannot substitute that for either an existing and
equivalent piece of information (b53, bcm_sf2, qca8k), and there is only
one for which we need to introduce a helper: mt7530. We do introduce
dsa_ds_get_cpu_
