kernel.git/drivers/net/ethernet/mscc, branch linux-5.8.y

net: mscc: ocelot: divide watermark value by 60 when writing to SYS_ATOP

2020-10-14T09:55:58Z

[ Upstream commit 601e984f23abcaa7cf3eb078c13de4db3cf6a4f0 ] Tail dropping is enabled for a port when: 1. A source port consumes more packet buffers than the watermark encoded in SYS:PORT:ATOP_CFG.ATOP. AND 2. Total memory use exceeds the consumption watermark encoded in SYS:PAUSE_CFG:ATOP_TOT_CFG. The unit of these watermarks is a 60 byte memory cell. That unit is programmed properly into ATOP_TOT_CFG, but not into ATOP. Actually when written into ATOP, it would get truncated and wrap around. Fixes: a556c76adc05 ("net: mscc: Add initial Ocelot switch support") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: mscc: ocelot: extend watermark encoding function

2020-10-14T09:55:58Z

[ Upstream commit aa92d836d5c40a7e21e563a272ad177f1bfd44dd ] The ocelot_wm_encode function deals with setting thresholds for pause frame start and stop. In Ocelot and Felix the register layout is the same, but for Seville, it isn't. The easiest way to accommodate Seville hardware configuration is to introduce a function pointer for setting this up. Signed-off-by: Maxim Kochetkov Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: mscc: ocelot: split writes to pause frame enable bit and to thresholds

2020-10-14T09:55:58Z

[ Upstream commit e8e6e73db14273464b374d49ca7242c0994945f3 ] We don't want ocelot_port_set_maxlen to enable pause frame TX, just to adjust the pause thresholds. Move the unconditional enabling of pause TX to ocelot_init_port. There is no good place to put such setting because it shouldn't be unconditional. But at the moment it is, we're not changing that. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: mscc: ocelot: rename ocelot_board.c to ocelot_vsc7514.c

2020-10-14T09:55:58Z

[ Upstream commit 589aa6e7c9de322d47eb33a5cee8cc38838319e6 ] To follow the model of felix and seville where we have one platform-specific file, rename this file to the actual SoC it serves. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: mscc: ocelot: fix encoding destination ports into multicast IPv4 address

2020-08-19T06:26:14Z

[ Upstream commit 0897ecf7532577bda3dbcb043ce046a96948889d ] The ocelot hardware designers have made some hacks to support multicast IPv4 and IPv6 addresses. Normally, the MAC table matches on MAC addresses and the destination ports are selected through the DEST_IDX field of the respective MAC table entry. The DEST_IDX points to a Port Group ID (PGID) which contains the bit mask of ports that frames should be forwarded to. But there aren't a lot of PGIDs (only 80 or so) and there are clearly many more IP multicast addresses than that, so it doesn't scale to use this PGID mechanism, so something else was done. Since the first portion of the MAC address is known, the hack they did was to use a single PGID for _flooding_ unknown IPv4 multicast (PGID_MCIPV4 == 62), but for known IP multicast, embed the destination ports into the first 3 bytes of the MAC address recorded in the MAC table. The VSC7514 datasheet explains it like this: 3.9.1.5 IPv4 Multicast Entries MAC table entries with the ENTRY_TYPE = 2 settings are interpreted as IPv4 multicast entries. IPv4 multicasts entries match IPv4 frames, which are classified to the specified VID, and which have DMAC = 0x01005Exxxxxx, where xxxxxx is the lower 24 bits of the MAC address in the entry. Instead of a lookup in the destination mask table (PGID), the destination set is programmed as part of the entry MAC address. This is shown in the following table. Table 78: IPv4 Multicast Destination Mask Destination Ports Record Bit Field --------------------------------------------- Ports 10-0 MAC[34-24] Example: All IPv4 multicast frames in VLAN 12 with MAC 01005E112233 are to be forwarded to ports 3, 8, and 9. This is done by inserting the following entry in the MAC table entry: VALID = 1 VID = 12 MAC = 0x000308112233 ENTRY_TYPE = 2 DEST_IDX = 0 But this procedure is not at all what's going on in the driver. In fact, the code that embeds the ports into the MAC address looks like it hasn't actually been tested. This patch applies the procedure described in the datasheet. Since there are many other fixes to be made around multicast forwarding until it works properly, there is no real reason for this patch to be backported to stable trees, or considered a real fix of something that should have worked. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: mscc: ocelot: fix hardware timestamp dequeue logic

2020-07-27T19:04:40Z

The next hw timestamp should be snapshoot to the read registers only once the current timestamp has been read. If none of the pending skbs matches the current HW timestamp just gracefully flush the available timestamp by reading it. Signed-off-by: laurent brando Signed-off-by: Vladimir Oltean Signed-off-by: Yangbo Lu Signed-off-by: David S. Miller

net: mscc: allow offloading timestamping operations to the PHY

2020-05-27T21:54:31Z

This patch adds support for offloading timestamping operations not only to the Ocelot switch (as already supported) but to compatible PHYs. When both the PHY and the Ocelot switch support timestamping operations, the PHY implementation is chosen as the timestamp will happen closer to the medium. Signed-off-by: Antoine Tenart Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

net: mscc: use the PHY MII ioctl interface when possible

2020-05-27T21:54:31Z

Allow ioctl to be implemented by the PHY, when a PHY is attached to the Ocelot switch. In case the ioctl is a request to set or get the hardware timestamp, use the Ocelot switch implementation for now. Signed-off-by: Antoine Tenart Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2020-05-24T20:47:27Z

The MSCC bug fix in 'net' had to be slightly adjusted because the register accesses are done slightly differently in net-next. Signed-off-by: David S. Miller

net: mscc: ocelot: fix address ageing time (again)

2020-05-22T23:15:21Z

ocelot_set_ageing_time has 2 callers: - felix_set_ageing_time: from drivers/net/dsa/ocelot/felix.c - ocelot_port_attr_ageing_set: from drivers/net/ethernet/mscc/ocelot.c The issue described in the fixed commit below actually happened for the felix_set_ageing_time code path only, since ocelot_port_attr_ageing_set was already dividing by 1000. So to make both paths symmetrical (and to fix addresses getting aged way too fast on Ocelot), stop dividing by 1000 at caller side altogether. Fixes: c0d7eccbc761 ("net: mscc: ocelot: ANA_AUTOAGE_AGE_PERIOD holds a value in seconds, not ms") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller