> I am actually in the process of cleaning up my patches that add
> platform_data support to net/dsa/dsa2.c this time with an user, and
> hopefully a couple more after that, but that maintains the existing
> struct dsa_chip_data as-is, no new additions are required, and this
> would be purely for n
On 01/04/2017 06:01 AM, Andrew Lunn wrote:
> On Wed, Jan 04, 2017 at 08:38:03AM +0100, John Crispin wrote:
>> From: Andrew Lunn
>>
>> Some boards have two CPU interfaces connected to the switch, e.g. WiFi
>> access points, with 1 port labeled WAN, 4 ports labeled lan1-lan4, and
>> two port conne
On Wed, Jan 04, 2017 at 08:38:03AM +0100, John Crispin wrote:
> From: Andrew Lunn
>
> Some boards have two CPU interfaces connected to the switch, e.g. WiFi
> access points, with 1 port labeled WAN, 4 ports labeled lan1-lan4, and
> two port connected to the SoC.
>
> This patch extends DSA to all
On Wed, Jan 04, 2017 at 08:38:03AM +0100, John Crispin wrote:
> static int dsa_user_port_apply(struct device_node *port, u32 index,
> @@ -475,6 +475,28 @@ static int dsa_cpu_parse(struct device_node *port, u32
> index,
>
> dst->rcv = dst->tag_ops->rcv;
>
> + dev_hold(ethernet_dev);
From: Andrew Lunn
Some boards have two CPU interfaces connected to the switch, e.g. WiFi
access points, with 1 port labeled WAN, 4 ports labeled lan1-lan4, and
two port connected to the SoC.
This patch extends DSA to allows both CPU ports to be used. The "cpu"
node in the DSA tree can now have a