From: Vivien Didelot
Date: Tue, 17 May 2016 11:39:23 -0400
> Do we want to send this fix to -net as well?
net isn't open and is irrelevant right now, everything goes through the net-next
tree since we are in the merge window.
From: Vivien Didelot
Date: Tue, 17 May 2016 11:39:23 -0400
> Do we want to send this fix to -net as well?
net isn't open and is irrelevant right now, everything goes through the net-next
tree since we are in the merge window.
Hi Andrew,
Andrew Lunn writes:
>> Do we want to send this fix to -net as well?
>
> I don't see this bug as being highly critical that it needs to be
> fixed immediately.
>
> I would suggest we wait until -rc1 is out, and then produce a backport
> version. Given the changes we
Hi Andrew,
Andrew Lunn writes:
>> Do we want to send this fix to -net as well?
>
> I don't see this bug as being highly critical that it needs to be
> fixed immediately.
>
> I would suggest we wait until -rc1 is out, and then produce a backport
> version. Given the changes we have made to that
On Tue, May 17, 2016 at 11:39:23AM -0400, Vivien Didelot wrote:
> Hi David,
>
> David Miller writes:
>
> > From: Vivien Didelot
> > Date: Fri, 13 May 2016 21:28:28 -0400
> >
> >> Hi David,
> >>
> >> Vivien Didelot
On Tue, May 17, 2016 at 11:39:23AM -0400, Vivien Didelot wrote:
> Hi David,
>
> David Miller writes:
>
> > From: Vivien Didelot
> > Date: Fri, 13 May 2016 21:28:28 -0400
> >
> >> Hi David,
> >>
> >> Vivien Didelot writes:
> >>
> >>> Now that the bridge code defers the switchdev port state
Hi David,
David Miller writes:
> From: Vivien Didelot
> Date: Fri, 13 May 2016 21:28:28 -0400
>
>> Hi David,
>>
>> Vivien Didelot writes:
>>
>>> Now that the bridge code defers the switchdev port
Hi David,
David Miller writes:
> From: Vivien Didelot
> Date: Fri, 13 May 2016 21:28:28 -0400
>
>> Hi David,
>>
>> Vivien Didelot writes:
>>
>>> Now that the bridge code defers the switchdev port state setting, there
>>> is no need to defer the port STP state change within the mv88e6xxx
From: Vivien Didelot
Date: Fri, 13 May 2016 21:28:28 -0400
> Hi David,
>
> Vivien Didelot writes:
>
>> Now that the bridge code defers the switchdev port state setting, there
>> is no need to defer the port STP state
From: Vivien Didelot
Date: Fri, 13 May 2016 21:28:28 -0400
> Hi David,
>
> Vivien Didelot writes:
>
>> Now that the bridge code defers the switchdev port state setting, there
>> is no need to defer the port STP state change within the mv88e6xxx code.
>> Thus get rid of the driver's bridge
Hi David,
Vivien Didelot writes:
> Now that the bridge code defers the switchdev port state setting, there
> is no need to defer the port STP state change within the mv88e6xxx code.
> Thus get rid of the driver's bridge work code.
>
> This also fixes a race
Hi David,
Vivien Didelot writes:
> Now that the bridge code defers the switchdev port state setting, there
> is no need to defer the port STP state change within the mv88e6xxx code.
> Thus get rid of the driver's bridge work code.
>
> This also fixes a race condition where the DSA layer assumes
Now that the bridge code defers the switchdev port state setting, there
is no need to defer the port STP state change within the mv88e6xxx code.
Thus get rid of the driver's bridge work code.
This also fixes a race condition where the DSA layer assumes that the
bridge code already set the
Now that the bridge code defers the switchdev port state setting, there
is no need to defer the port STP state change within the mv88e6xxx code.
Thus get rid of the driver's bridge work code.
This also fixes a race condition where the DSA layer assumes that the
bridge code already set the
14 matches
Mail list logo