On Mon, Jun 03, 2013 at 04:34:25PM +0200, Thomas Gleixner wrote:
> B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
> > In ktime_get_update_offsets, calculate the current time in the same
> > way as in ktime_get.
> >
> > On 32-bit systems, the current time i
longer fit in 31-bits (2038-01-19 03:14:07 UTC). This will send
hrtimer_interrupt into an infinite loop on some architectures (arm),
or emit an oops on others(x86).
Signed-off-by: Tobias Waldekranz
---
kernel/time/timekeeping.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
Two tracepoints for now:
* `phy_interrupt` Pretty self-explanatory.
* `phy_state_change` Whenever the PHY's state machine is run, trace
the old and the new state.
Signed-off-by: Tobias Waldekranz
---
drivers/net/phy/phy.c | 4 +++
include/trace/events/phy.h
Two tracepoints for now:
* `phy_interrupt` Pretty self-explanatory.
* `phy_state_change` Whenever the PHY's state machine is run, trace
the old and the new state.
Signed-off-by: Tobias Waldekranz
Acked-by: Steven Rostedt (VMware)
---
v1 -> v2:
* Actually include the enti
On Wed, Feb 10, 2021 at 10:41, Mickey Rachamim wrote:
>> Until that day arrives, are there any chances of Marvell opening up CPSS in
>> the same way DSDT was re-licensed some years back?
> The CPSS code is available to everyone on Marvell Extranet (Requires simple
> registration process)
Right,
On Sat, Jan 30, 2021 at 21:43, DENG Qingfang wrote:
> Having multiple destination ports for a unicast address does not make
> sense.
> Make port_db_load_purge override existent unicast portvec instead of
> adding a new port bit.
Is this the layer we want to solve this problem at? What are the
con
On Sun, Jan 31, 2021 at 09:13, DENG Qingfang wrote:
> On Sun, Jan 31, 2021 at 8:39 AM Vladimir Oltean wrote:
>>
>> Tobias has a point in a way too, you should get used to adding the
>> 'master static' flags to your bridge fdb commands, otherwise weird
>> things like this could happen. The faulty
On Thu, Feb 04, 2021 at 21:16, Jakub Kicinski wrote:
> On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote:
>> From: Serhiy Boiko
>>
>> The following features are supported:
>>
>> - LAG basic operations
>> - create/delete LAG
>> - add/remove a member to LAG
>> - en
On Mon, Feb 08, 2021 at 13:05, Jakub Kicinski wrote:
> On Mon, 08 Feb 2021 20:54:29 +0100 Tobias Waldekranz wrote:
>> On Thu, Feb 04, 2021 at 21:16, Jakub Kicinski wrote:
>> > On Wed, 3 Feb 2021 18:54:56 +0200 Vadym Kochan wrote:
>> >> From: Serhiy Boiko
>&
On Mon, Feb 08, 2021 at 23:30, Andrew Lunn wrote:
>> > I took a quick look at it, and what I found left me very puzzled. I hope
>> > you do not mind me asking a generic question about the policy around
>> > switchdev drivers. If someone published a driver using something similar
>> > to the follow
On Tue, Feb 09, 2021 at 20:31, Mickey Rachamim wrote:
> Hi Andrew, Jakub, Tobias,
>
> On Tuesday, February 9, 2021 7:35 PM Jakub Kicinski wrote:
>> Sounds like we have 3 people who don't like FW-heavy designs dominating the
>> kernel - this conversation can only go one way.
>> Marvell, Plvision
idge port is handled in the next
> patches.
>
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
t;
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
But this new bridge port will not see any STP state
> change notification and will remain FORWARDING, which is how the
> standalone code leaves it in.
>
> Add a function to the bridge which retrieves the current STP state, such
> that drivers can synchronize to it when they may have
emitted by the
> bridge for this port.
>
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Make sure that the multicast router setting of the bridge is picked up
> correctly by DSA when joining, regardless of whether there are
> sandwiched interfaces or not. The SWITCHDEV_ATTR_ID_BRIDGE_MROUTER port
> att
creation time, so:
> (a) drivers had to hardcode the initial value for the address ageing time,
> because they didn't get any notification
> (b) that hardcoded value can be out of sync, if the user changes the
> ageing time before enslaving the port to the bridge
>
> Si
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> When a DSA port joins a LAG that already had an FDB entry pointing to it:
>
> ip link set bond0 master br0
> bridge fdb add dev bond0 00:01:02:03:04:05 master static
> ip link set swp0 master bond0
>
> the DSA port
7;ll think we're offloading the bridge master of the LAG, when in
> fact we're not even offloading the LAG. In turn, this will make us set
> skb->offload_fwd_mark = true, which is incorrect and the bridge doesn't
> like it.
>
> Signed-off-by: Vladimir Oltean
> ---
Reviewed-by: Tobias Waldekranz
On Fri, Mar 19, 2021 at 01:18, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> On reception of an skb, the bridge checks if it was marked as 'already
> forwarded in hardware' (checks if skb->offload_fwd_mark == 1), and if it
> is, it puts a mark of its own on that skb, with the switchdev mark
On Mon, Mar 22, 2021 at 18:19, Vladimir Oltean wrote:
> On Mon, Mar 22, 2021 at 04:44:41PM +0100, Tobias Waldekranz wrote:
>> I do not know if it is a problem or not, more of an observation: This is
>> not guaranteed to be an exact replay of the events that the bridge port
&g
On Thu, Apr 15, 2021 at 02:39, Vladimir Oltean wrote:
> On Wed, Apr 14, 2021 at 08:39:53PM +0200, Tobias Waldekranz wrote:
>> In order to have two entries for the same destination, they must belong
>> to different FIDs. But that FID is also used for automatic learning. So
>
On Sun, Apr 11, 2021 at 21:50, Vladimir Oltean wrote:
> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
>> On Sat, 10 Apr 2021 15:34:46 +0200
>> Ansuel Smith wrote:
>>
>> > Hi,
>> > this is a respin of the Marek series in hope that this time we can
>> > finally make some progress wi
On Mon, Apr 12, 2021 at 17:35, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 02:46:11PM +0200, Tobias Waldekranz wrote:
>> On Sun, Apr 11, 2021 at 21:50, Vladimir Oltean wrote:
>> > On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote:
>> >> On S
On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> On Mon, 12 Apr 2021 14:46:11 +0200
> Tobias Waldekranz wrote:
>
>> I agree. Unless you only have a few really wideband flows, a LAG will
>> typically do a great job with balancing. This will happen without the
>
On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
>> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 14:46:11 +0200
>> > Tobias Waldekranz wrote:
>> >
>&
On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
> On Mon, 12 Apr 2021 23:22:45 +0200
> Tobias Waldekranz wrote:
>
>> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 14:46:11 +0200
>> > Tobias Waldekranz wrote:
>> >
>&g
On Tue, Apr 13, 2021 at 01:06, Vladimir Oltean wrote:
> On Mon, Apr 12, 2021 at 11:49:22PM +0200, Tobias Waldekranz wrote:
>> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
>> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
>> >> On Mon
On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote:
> On Tue, 13 Apr 2021 00:05:51 +0200
> Tobias Waldekranz wrote:
>
>> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
>> > On Mon, 12 Apr 2021 23:22:45 +0200
>> > Tobias Waldekranz wrote:
>> >
>&g
On Tue, Apr 13, 2021 at 01:09, Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:55, Marek Behun wrote:
>> On Tue, 13 Apr 2021 00:05:51 +0200
>> Tobias Waldekranz wrote:
>>
>>> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
>>> > On Mo
On Tue, Apr 13, 2021 at 01:54, Marek Behun wrote:
> On Tue, 13 Apr 2021 01:13:53 +0200
> Tobias Waldekranz wrote:
>
>> > ...you could get the isolation in place. But you will still lookup the
>> > DA in the ATU, and there you will find a destination of either cpu0 or
&
On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote:
> On Tue, 13 Apr 2021 01:54:50 +0200
> Marek Behun wrote:
>
>> I will look into this, maybe ask some follow-up questions.
>
> Tobias,
>
> it seems that currently the LAGs in mv88e6xxx driver do not use the
> HashTrunk feature (which can be enabled
On Tue, Apr 13, 2021 at 17:14, Marek Behun wrote:
> On Tue, 13 Apr 2021 16:46:32 +0200
> Tobias Waldekranz wrote:
>
>> On Tue, Apr 13, 2021 at 02:27, Marek Behun wrote:
>> > On Tue, 13 Apr 2021 01:54:50 +0200
>> > Marek Behun wrote:
>> >
>> &g
On Wed, Apr 14, 2021 at 17:14, Marek Behun wrote:
> On Tue, 13 Apr 2021 20:16:24 +0200
> Tobias Waldekranz wrote:
>
>> You could imagine a different mode in which the DSA driver would receive
>> the bucket allocation from the bond/team driver (which in turn could
>
aking VLAN filtering.
>
> When the VTU entry is initially created, those bits are all zero, and
> we should make sure to keep them that way when the entry is updated.
>
> Fixes: 92307069a96c (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097)
> Signed-off-by: Rasmus Villemoes
R
n assembling the fid from VTU op [3:0]
> and [11:8].
>
> Signed-off-by: Rasmus Villemoes
We might also want to give mv88e6250_g1_vtu_loadpurge the same
treatment.
Reviewed-by: Tobias Waldekranz
Tested-by: Tobias Waldekranz
On Mon, Nov 09, 2020 at 02:30, Vladimir Oltean wrote:
> On Mon, Nov 09, 2020 at 12:59:39AM +0100, Andrew Lunn wrote:
>> We also need to make sure the static entries get removed correctly
>> when a host moves. The mv88e6xxx will not replace a static entry with
>> a dynamically learned one. It will
On Mon, Nov 09, 2020 at 12:03, Vladimir Oltean wrote:
> On Mon, Nov 09, 2020 at 09:09:37AM +0100, Tobias Waldekranz wrote:
>> one. But now you have also increased the background load of an already
>> choked resource, the MDIO bus.
>
> In practice, DSA switches are already ve
On Mon Nov 9, 2020 at 3:38 PM CET, Vladimir Oltean wrote:
> On Mon, Nov 09, 2020 at 02:31:11PM +0200, Vladimir Oltean wrote:
> > I need to sit on this for a while. How many DSA drivers do we have that
> > don't do SA learning in hardware for CPU-injected packets? ocelot/felix
> > and mv88e6xxx? Who
The current construct for inserting the `scripts/gdb/` directory into
the python path requires `vmlinux-gdb.py` to be symlinked in the root of
the kernel build tree.
By first resolving the symlink and inserting that path, the symlink can
be placed in an arbitrary directory.
Signed-off-by: Tobias
40 matches
Mail list logo