On 30/06/2019 03:13, vto...@gmail.com wrote:
> On 30/06/2019 02:37, vto...@gmail.com wrote:
>> On 30/06/2019 01:23, vto...@gmail.com wrote:
>>> On 30/06/2019 01:11, Andrew Lunn wrote:
>>>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vto...@googlemail.com wrote:
>>>>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>>>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vto...@googlemail.com wrote:
>>>>>>> * DSA MV88E6060
>>>>>>> * iproute2 v.5.0.0-2.0
>>>>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>>>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>>>>> does not even have support for offloading bridging between ports to
>>>>>> the switch.
>>>>>>
>>>>>> The data sheet for this device is open. So if you want to hack on the
>>>>>> driver, you could do.
>>>>>>
>>>>>> Andrew
>>>>> Are you sure? That is a bit confusing after reading
>>>>> https://lore.kernel.org/patchwork/patch/575746/
>>>> Quoting that patch:
>>>>
>>>> This commit implements the switchdev operations to add, delete
>>>> and dump VLANs for the Marvell 88E6352 and compatible switch
>>>> chips.
>>>>
>>>> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
>>>> the mv88e6060. And by compatible switches, he meant those in the 6352
>>>> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>>>>
>>>> Andrew
>>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>>> that happened to me apparently (being said simpleton).
>>> That may as it be, and pardon my continued ignorance, how is it
>>> explained then that a command as
>>>
>>> # bridge v a dev {bridge} self vid {n} untagged pvid
>>>
>>> reflects in
>>>
>>> # bridge v s
>>> a/o
>>> # bridge mo
>>>
>>> ?
>>>
>>> If the commands are not implemented one would expect them to fail in the
>>> first place or not reflecting a change at all?
>>>
>>>
>> As stated in the initial message - kernel conf
>>
>> CONFIG_NET_DSA_MV88E6060=y
>> CONFIG_NET_DSA_MV88E6XXX=y
>> CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
>>
> Just figured that it is a Marvell 88E6176-TFJ2. Thus that cannot be the
> cause, also considering the that the commands are executing and changes
> being reflected.
>
> However, the loss of access to the node is a mystery.
>
> Apparently the filter is doing its job as in isolating access to the
> bridge if connecting though an enslaved device.
> And yet the bridge is still fully accessible from other devices that or
> not enslaved by that bridge. As if the filter is inverted.
>
The node's kernel log is showing during boot time repeated entries:
mv88e6085 f1072004.mdio-mii:10 lan{n}: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already used by br-{n}
Could there be a correlation with the described issue?
Is there way to debug the issue otherwise?
