On 8/11/19 6:22 AM, Andrew Lunn wrote:
> Hi Ioana
>
>> >> + struct ethsw_port_priv *port_priv = netdev_priv(netdev);
>> >> + struct ethsw_core *ethsw = port_priv->ethsw_data;
>> >> + int i, err;
>> >> +
>> >> + for (i = 0; i < ethsw->sw_attr.num_ifs; i++)
>> >> + if (ethsw->ports[i]->bridge_dev &&
>> >> + (ethsw->ports[i]->bridge_dev != upper_dev)) {
>> >> + netdev_err(netdev,
>> >> + "Another switch port is connected to
>> %s\n",
>> >> + ethsw->ports[i]->bridge_dev->name);
>> >> + return -EINVAL;
>> >> + }
>> >
>> > Am i reading this correct? You only support a single bridge? The
>> > error message is not very informative. Also, i think you should be
>> > returning EOPNOTSUPP, indicating the offload is not possible. Linux
>> > will then do it in software. If it could actually receive/transmit the
>> > frames....
>> >
>>
>> Yes, we only support a single bridge.
>
> That is a pretty severe restriction for a device of this class. Some
> of the very simple switches DSA support have a similar restriction,
> but in general, most do support multiple bridges.
>
Let me make a distinction here: we do no support multiple bridges on the
same DPSW object but we do support multiple DPSW objects, each with its
bridge.
> Are there any plans to fix this?
>
We had some internal discussions on this, the hardware could support
this kind of further partitioning the switch object but, at the moment,
the firmware doesn't.
> Thanks
> Andrew
>
