From: Florian Fainelli
Date: Fri, 1 Mar 2019 09:54:07 -0800
> David, please discard this version, I will submit a version that
> properly emulates the prepare/commit phase such that no assumptions are
> broken, this will take care of both issues at once. Thanks!
Ok.
On 3/1/19 9:52 AM, Florian Fainelli wrote:
[snip]
>> Tested-by: Michal Vokáč
>>
>> I am not sure what was the original problem as I could not find the
>> thread where Heiner reported the issue but with the latest version
>> next-20190228 I get this error with QCA8334 switch:
>
> Thanks Michal.
On 3/1/19 2:34 AM, Michal Vokáč wrote:
> On 01. 03. 19 0:49, Florian Fainelli wrote:
>> Because we skip the prepare phase, we would not get a chance to have the
>> port_vlan_prepare() callback return -EOPNOTSUPP and tell us about that.
>> This causes problems with mv88e6xxx which specifically check
On 01. 03. 19 0:49, Florian Fainelli wrote:
Because we skip the prepare phase, we would not get a chance to have the
port_vlan_prepare() callback return -EOPNOTSUPP and tell us about that.
This causes problems with mv88e6xxx which specifically checks for VLAN
ID = 0. Turns out we do not actually
On 01.03.2019 00:49, Florian Fainelli wrote:
> Because we skip the prepare phase, we would not get a chance to have the
> port_vlan_prepare() callback return -EOPNOTSUPP and tell us about that.
> This causes problems with mv88e6xxx which specifically checks for VLAN
> ID = 0. Turns out we do not ac
Because we skip the prepare phase, we would not get a chance to have the
port_vlan_prepare() callback return -EOPNOTSUPP and tell us about that.
This causes problems with mv88e6xxx which specifically checks for VLAN
ID = 0. Turns out we do not actually need to program that VLAN ID since
it should b
