On 6/13/25 12:33, Vincent Knecht via B4 Relay wrote:
From: Vincent Knecht
Add bindings for qcom,msm8939-camss in order to support the camera
subsystem for MSM8939.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Vincent Knecht
Reviewed-by: Vladimir Zapolskiy
--
Best wishes,
Vladimir
Hi Vincent.
On 6/8/25 00:42, Vincent Knecht wrote:
Le vendredi 06 juin 2025 à 13:46 +0300, Vladimir Zapolskiy a écrit :
Hello Vincent.
Hi Vladimir,
thank you for the review.
On 6/2/25 20:27, Vincent Knecht via B4 Relay wrote:
From: Vincent Knecht
Add bindings for qcom,msm8939-camss in
geset published on
linux-media [1] before v1 of the MSM8939 platform support in CAMSS,
due to a merge conflict this platform changeset should be rebased IMHO.
[1]
https://lore.kernel.org/all/20250513142353.2572563-4-vladimir.zapols...@linaro.org/
--
Best wishes,
Vladimir
;
+
+interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy1",
+ "ispif",
+ "vfe0";
+
+iommus = <&apps_iommu 3>;
+
+power-domains = <&gcc VFE_GDSC>;
+
+vdda-supply = <®_2v8>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@1 {
+reg = <1>;
+csiphy1_ep: endpoint {
There should be an empty line between the end of the list of properties
and the beginning of the list of children device tree nodes.
+clock-lanes = <1>;
Please remove 'clock-lanes' propoerty from here.
+data-lanes = <0 2>;
+remote-endpoint = <&sensor_ep>;
+};
+};
+};
+};
--
Best wishes,
Vladimir
s {
+ vdda-supply = <&pm8916_l2>;
+};
+
What is the benefit of enabling CAMSS on a board without any sensors
connected to the SoC? Likely the board specific change has to be removed.
--
Best wishes,
Vladimir
8670dc33f48b ("net: dsa: felix: update base time of time-aware shaper
when adjusting PTP time")
Reported-by: Richie Pearn
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/felix_vsc9959.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/oc
This snippet will be necessary for a future isochron-based test, so
provide a simpler high-level interface for counting the received
packets.
Signed-off-by: Vladimir Oltean
---
tools/testing/selftests/drivers/net/ocelot/psfp.sh | 7 +--
tools/testing/selftests/net/forwarding/tsn_lib.sh
he test still works properly.
Signed-off-by: Vladimir Oltean
---
tools/testing/selftests/drivers/net/ocelot/psfp.sh | 1 +
tools/testing/selftests/net/forwarding/tsn_lib.sh | 5 +
2 files changed, 6 insertions(+)
diff --git a/tools/testing/selftests/drivers/net/ocelot/psfp.sh
b/tools/test
0) and one back into the present.
Symlink it from tools/testing/selftests/drivers/net/dsa, because usually
DSA ports have the same MAC address, and we need STABLE_MAC_ADDRS=yes
from its forwarding.config for the test to run successfully.
Signed-off-by: Vladimir Oltean
---
.../selftests/drive
k_jump_backward() is the first in the test suite, and
without patch 1/4, it is only supposed to fail the _first_ time when
running after a clean boot.
Vladimir Oltean (4):
net: dsa: felix: fix broken taprio gate states after clock jump
selftests: net: tsn_lib: create common helper for co
1p"
test.
- we need to test that the usual paths of reaching a configuration with
no PVID on a bridge port are all covered and they all reach the same
state.
Signed-off-by: Vladimir Oltean
---
.../net/forwarding/bridge_vlan_aware.sh | 96 ++-
1 file changed, 95
r 'stable'. Realistically, that is as far as this fix
needs to be propagated to.
Fixes: be0576fed6d3 ("net: mscc: ocelot: move the logic to drop 802.1p traffic
to the pvid deletion")
Signed-off-by: Vladimir Oltean
---
drivers/net/ethernet/mscc/ocelot.c | 6 ++
1 file chang
040 02 01 00 00 04 00 00 00 00 00 00 00 00 00 00 00
||
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
||
*
0080
Fixes: 40ce9798794f ("nvmem: add QTI SDAM driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Luca Weiss
R
ne 1 position 1
lane 2 position 2
lane 3 position 3
clock lane position 7
no lane polarities defined, assuming not inverted
assuming media bus type MIPI CSI-2 D-PHY (5)
= end parsing endpoint /soc@0/camss@ac6a000/ports/port@2/endpoint
Tested-by: Vladimir Zapolskiy
Reviewed-by: Vladimir Zapo
On 12/13/24 13:34, Bryan O'Donoghue wrote:
On 13/12/2024 11:24, Luca Weiss wrote:
On Fri Dec 13, 2024 at 11:50 AM CET, Vladimir Zapolskiy wrote:
On 12/13/24 11:34, Krzysztof Kozlowski wrote:
On Mon, Dec 09, 2024 at 01:01:05PM +0100, Luca Weiss wrote:
The CSIPHY of Qualcomm SoCs support
On 12/13/24 13:22, Luca Weiss wrote:
On Fri Dec 13, 2024 at 12:02 PM CET, Vladimir Zapolskiy wrote:
On 12/9/24 14:32, Bryan O'Donoghue wrote:
On 09/12/2024 12:01, Luca Weiss wrote:
Currently the Qualcomm CAMSS driver only supports D-PHY while the
hardware on most SoCs also supports
break all old board dtbs, which is not just bad, but NAK.
V4L2_MBUS_UNKNOWN shall be properly handled without the risk of regressions.
csd->interface.csiphy_id = vep.base.port;
mipi_csi2 = &vep.bus.mipi_csi2;
Reviewed-by: Bryan O'Donoghue
--
Best wishes,
Vladimir
Best wishes,
Vladimir
On Mon, Dec 02, 2024 at 10:29:31PM +0100, Christian Marangi wrote:
> > Also I just notice msend suffer the very same problem...
> >
> > root@OpenWrt:~# ip vrf exec vlan1 msend -g ff2e::0102:0304 -I lan1 -c 1
> > Now sending to multicast group: [ff2e::0102:0304]:
> > sendto: Address family not
On Mon, Dec 02, 2024 at 09:39:15PM +0100, Christian Marangi wrote:
> Mhh the problem seems to be -c
>
> Let me post some outputs...
>
> root@OpenWrt:~# ping -V
> ping from iputils 20240117
> libcap: no, IDN: no, NLS: no, error.h: no, getrandom(): yes, __fpending(): yes
> root@OpenWrt:~# ping -c
On Sat, Nov 30, 2024 at 12:33:10PM +0100, Christian Marangi wrote:
> It seems real hardware requires some time to stabilize and actually
> works after an 'ip link up'. This is not the case for veth as everything
> is simulated but this is a requirement for real hardware to permit
> receiving packet
On Sat, Nov 30, 2024 at 04:46:14PM +0100, Christian Marangi wrote:
> On Sat, Nov 30, 2024 at 05:43:07PM +0200, Vladimir Oltean wrote:
> > On Sat, Nov 30, 2024 at 12:33:09PM +0100, Christian Marangi wrote:
> > > If the coreutils variant of ping is used instead of the busybox one,
On Sat, Nov 30, 2024 at 12:33:09PM +0100, Christian Marangi wrote:
> If the coreutils variant of ping is used instead of the busybox one, the
> ping_do() command is broken. This comes by the fact that for coreutils
> ping, the ping IP needs to be the very last elements.
>
> To handle this, reorder
On Mon, Sep 30, 2024 at 03:35:43PM +0900, Kacper Ludwinski wrote:
> This typo has an impact on results of the test results,
> potentially leading to wrong conclusions regarding
> the functionality of a network device.
Did you test this? You are effectively introducing a new test.
Could you include
Hi Kacper,
On Fri, Sep 27, 2024 at 08:28:24PM +0900, Kacper Ludwinski wrote:
> Fix typo.
> Currently, the second bridge command overwrites the first one.
> Fix this by adding this VID to the interface behind $swp2.
>
> Fixes: 476a4f05d9b8 ("selftests: forwarding: add a no_forwarding.sh test")
> S
e
> enetc was enabled. Fix it by automatically select the enetc-ierb module.
>
> Fixes: e7d48e5fbf30 ("net: enetc: add a mini driver for the Integrated
> Endpoint Register Block")
> Signed-off-by: Michael Walle
> ---
Acked-by: Vladimir Oltean
On Tue, Apr 20, 2021 at 01:30:51PM +0300, Vladimir Oltean wrote:
> On Tue, Apr 20, 2021 at 10:28:45AM +, Xiaoliang Yang wrote:
> > Hi Vladimir,
> >
> > On Tue, Apr 20, 2021 at 16:27:10AM +0800, Vladimir Oltean wrote:
> > >
> > > On Tue, Apr 20, 2021 at
o reserve
> guard band on each GCL. Users can manually add guard band time for each
> schedule queues in their configuration if they want.
>
> Signed-off-by: Xiaoliang Yang
> ---
Reviewed-by: Vladimir Oltean
On Tue, Apr 20, 2021 at 10:28:45AM +, Xiaoliang Yang wrote:
> Hi Vladimir,
>
> On Tue, Apr 20, 2021 at 16:27:10AM +0800, Vladimir Oltean wrote:
> >
> > On Tue, Apr 20, 2021 at 03:06:40AM +, Xiaoliang Yang wrote:
> >> Hi Vladimir.
> >>
> >>
On Tue, Apr 20, 2021 at 03:06:40AM +, Xiaoliang Yang wrote:
> Hi Vladimir.
>
> On Mon, Apr 19, 2021 at 20:38PM +0800, Vladimir Oltean wrote:
> >
> >What is a scheduled queue? When time-aware scheduling is enabled on
> >the port, why are some queues scheduled a
On Tue, Apr 20, 2021 at 07:33:39AM +, Y.b. Lu wrote:
> > > + /* For two-step timestamp, retrieve ptp_cmd in DSA_SKB_CB_PRIV
> > > + * and timestamp ID in clone->cb[0].
> > > + * For one-step timestamp, retrieve ptp_cmd in DSA_SKB_CB_PRIV.
> > > + */
> > > + u8 *ptp_cmd = DSA_SKB_CB_PRIV(skb)
Hi Xiaoliang,
On Mon, Apr 19, 2021 at 06:25:30PM +0800, Xiaoliang Yang wrote:
> ALWAYS_GUARD_BAND_SCH_Q bit in TAS config register is descripted as
> this:
> 0: Guard band is implemented for nonschedule queues to schedule
> queues transition.
> 1: Guard band is implemented for
On Fri, Apr 16, 2021 at 08:36:55PM +0800, Yangbo Lu wrote:
> Although HWTSTAMP_TX_ONESTEP_SYNC existed in ioctl for hardware timestamp
> configuration, the PTP Sync one-step timestamping had never been supported.
>
> This patch is to truely support it.
Actually the ocelot switchdev driver does su
, port, skb, clone))
> + return false;
>
> - return false;
> + return true;
Considering the changes you'll have to make to patch 1 (changing the
return value and populating DSA_SKB_CB(skb)->clone at the end of this
function:
Reviewed-by: Vladimir Oltean
On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote:
> Optimization could be done on dsa_skb_tx_timestamp(), and dsa device
> drivers should adapt to it.
>
> - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in
> port_txtstamp, so that most skbs not requiring tx timest
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
> if all ports use their own FID, all the switched traffic will have to be
> flooded
On Tue, Apr 13, 2021 at 12:26:52AM +0200, Tobias Waldekranz wrote:
> 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 M
On Tue, Apr 13, 2021 at 12:04:57AM +0200, Marek Behun wrote:
> On Mon, 12 Apr 2021 19:32:11 +0300
> Vladimir Oltean wrote:
>
> > On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> > > On Sun, Apr 11, 2021 at 09:50:17PM +0300, 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, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >> > On M
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:
> >
> >> I agree. Unless you only have a few really wideband flows, a LAG will
> >> typically do a great job w
On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> >
> > So I'd be tempted to say 'tough luck' if all your ports are not up, and
> > the ones that are are assigned sta
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 Sat, 10 Apr 2021 15:34:46 +0200
> >> Ansuel Smith wrote:
> >>
&
On Sun, Apr 11, 2021 at 09:50:17PM +0300, 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 t
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 with dsa supporting multi-cpu port.
> >
> > This implementation
On Sun, Apr 11, 2021 at 10:04:11AM -0700, Stephen Hemminger wrote:
> On Sat, 10 Apr 2021 15:34:50 +0200
> Ansuel Smith wrote:
>
> > Allow to change the interface to which a given interface is linked to.
> > This is useful in the case of multi-CPU port DSA, for changing the CPU
> > port of a given
On Thu, Apr 08, 2021 at 08:38:27PM +0200, Martin Blumenstingl wrote:
> PHY auto polling on the GSWIP hardware can be used so link changes
> (speed, link up/down, etc.) can be detected automatically. Internally
> GSWIP reads the PHY's registers for this functionality. Based on this
> automatic detec
On Sun, Apr 04, 2021 at 07:35:26AM +0200, Oleksij Rempel wrote:
> Am 04.04.21 um 02:02 schrieb Vladimir Oltean:
> > On Sat, Apr 03, 2021 at 07:14:56PM +0200, Oleksij Rempel wrote:
> >> Am 03.04.21 um 16:49 schrieb Andrew Lunn:
> >>>> @@ -31,6 +96,13 @@ static struc
On Sun, Apr 04, 2021 at 07:49:03AM +0200, Oleksij Rempel wrote:
> Am 04.04.21 um 01:21 schrieb Vladimir Oltean:
> > On Sat, Apr 03, 2021 at 05:05:34PM +0300, Vladimir Oltean wrote:
> >> On Sat, Apr 03, 2021 at 01:48:40PM +0200, Oleksij Rempel wrote:
> >>> Some switch
On Sat, Apr 03, 2021 at 01:48:48PM +0200, Oleksij Rempel wrote:
> This switch provides simple VLAN resolution database for 16 entries (VLANs).
> With this database we can cover typical functionalities as port based
> VLANs, untagged and tagged egress. Port based ingress filtering.
>
> The VLAN dat
On Sat, Apr 03, 2021 at 01:48:43PM +0200, Oleksij Rempel wrote:
> Make sure that all external port are actually isolated from each other,
> so no packets are leaked.
>
> Signed-off-by: Oleksij Rempel
> ---
> drivers/net/dsa/qca/ar9331.c | 145 ++-
> 1 file changed
On Sat, Apr 03, 2021 at 07:14:56PM +0200, Oleksij Rempel wrote:
> Am 03.04.21 um 16:49 schrieb Andrew Lunn:
> >> @@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff
> >> *skb,
> >>__le16 *phdr;
> >>u16 hdr;
> >>
> >> + if (dp->stp_state == BR_STATE_BLOCKING) {
> >> +
On Sat, Apr 03, 2021 at 05:25:16PM +0200, Andrew Lunn wrote:
> > +static int ar9331_sw_port_fdb_rmw(struct ar9331_sw_priv *priv,
> > + const unsigned char *mac,
> > + u8 port_mask_set,
> > + u8 port_mask_clr)
> > +{
On Sat, Apr 03, 2021 at 05:05:34PM +0300, Vladimir Oltean wrote:
> On Sat, Apr 03, 2021 at 01:48:40PM +0200, Oleksij Rempel wrote:
> > Some switches (for example ar9331) do not provide enough information
> > about forwarded packets. If the switch decision was made based on IPv4
>
On Sat, Apr 03, 2021 at 05:22:24PM +0200, Oleksij Rempel wrote:
> Off-topic question, this patch set stops to work after rebasing against
> latest netdev. I get following warning:
> ip l s lan0 master test
> RTNETLINK answers: Invalid argumen
>
> Are there some API changes?
Yes, it's likely that
On Sat, Apr 03, 2021 at 01:48:40PM +0200, Oleksij Rempel wrote:
> Some switches (for example ar9331) do not provide enough information
> about forwarded packets. If the switch decision was made based on IPv4
> or IPv6 header, we need to analyze it and set proper flag.
>
> Potentially we can do it
On Sat, Apr 03, 2021 at 03:26:36PM +0200, Oleksij Rempel wrote:
> On Sat, Apr 03, 2021 at 04:03:18PM +0300, Vladimir Oltean wrote:
> > Hi Oleksij,
> >
> > On Sat, Apr 03, 2021 at 01:48:41PM +0200, Oleksij Rempel wrote:
> > > The ar9331 switch is not forwardin
Hi Oleksij,
On Sat, Apr 03, 2021 at 01:48:41PM +0200, Oleksij Rempel wrote:
> The ar9331 switch is not forwarding IGMP and MLD packets if IGMP
> snooping is enabled. This patch is trying to mimic the HW heuristic to take
> same decisions as this switch would do to be able to tell the linux
> bridg
On Wed, Mar 24, 2021 at 01:20:33PM -0600, Rob Herring wrote:
> In addition, "fsl,ls1088a-dspi" is not known by the Linux driver, so a
> fallback is needed.
This is a good point, the LS1088A went completely off of my radar,
thanks for pointing it out.
On Wed, Mar 24, 2021 at 12:14:03PM -0600, Rob Herring wrote:
> On Tue, Mar 16, 2021 at 12:15:06PM +0200, Vladimir Oltean wrote:
> > On Tue, Mar 16, 2021 at 06:08:17AM +, Kuldeep Singh wrote:
> > > Compatible entries in conjugation require enum and const pair.
> > >
ed to zero. Fix this
> by assigning err.
>
> Addresses-Coverity: ("'Constant' variable guards dead code")
> Fixes: 22f67cdfae6a ("net: bridge: add helper to replay VLANs installed on
> port")
> Signed-off-by: Colin Ian King
> ---
Reviewed-by: Vladimir Oltean
On Tue, Mar 23, 2021 at 01:12:33PM +0200, Nikolay Aleksandrov wrote:
> On 23/03/2021 01:51, Vladimir Oltean wrote:
> > From: Vladimir Oltean
> >
> > When a switchdev port starts offloading a LAG that is already in a
> > bridge and has an FDB entry pointing to it:
On Mon, Mar 22, 2021 at 10:00:33PM +0200, Vladimir Oltean wrote:
> Hi Yunsheng,
>
> On Mon, Mar 22, 2021 at 05:09:16PM +0800, Yunsheng Lin wrote:
> > Currently pfifo_fast has both TCQ_F_CAN_BYPASS and TCQ_F_NOLOCK
> > flag set, but queue discipline by-pass does not work f
From: Vladimir Oltean
The premise of this change is that the switchdev port attributes and
objects offloaded by ocelot might have been missed when we are joining
an already existing bridge port, such as a bonding interface.
The patch pulls these switchdev attributes and objects from the bridge
From: Vladimir Oltean
This is a pretty noisy change that was broken out of the larger change
for replaying switchdev attributes and objects at bridge join time,
which is when these extack objects are actually used.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Reviewed-by
From: Vladimir Oltean
Similar to the DSA situation, ocelot supports LAG offload but treats
this scenario improperly:
ip link add br0 type bridge
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0
We do the same thing as we do there, which is to simulate a
From: Vladimir Oltean
If we join an already-created bridge port, such as a bond master
interface, then we can miss the initial switchdev notifications emitted
by the bridge for this port, while it wasn't offloaded by anybody.
Signed-off-by: Vladimir Oltean
---
net/dsa/dsa_priv.h | 3 +++
From: Vladimir Oltean
DSA currently assumes that the bridge port starts off with this
constellation of bridge port flags:
- learning on
- unicast flooding on
- multicast flooding on
- broadcast flooding on
just by virtue of code copy-pasta from the bridge layer (new_nbp).
This was a simple
From: Vladimir Oltean
Currently this simple setup with DSA:
ip link add br0 type bridge vlan_filtering 1
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0
will not work because the bridge has created the PVID in br_add_if ->
nbp_vlan_init, and it
From: Vladimir Oltean
I have a system with DSA ports, and udhcpcd is configured to bring
interfaces up as soon as they are created.
I create a bridge as follows:
ip link add br0 type bridge
As soon as I create the bridge and udhcpcd brings it up, I also have
avahi which automatically starts
From: Vladimir Oltean
DSA can properly detect and offload this sequence of operations:
ip link add br0 type bridge
ip link add bond0 type bond
ip link set swp0 master bond0
ip link set bond0 master br0
But not this one:
ip link add br0 type bridge
ip link add bond0 type bond
ip link set bond0
From: Vladimir Oltean
When a switchdev port starts offloading a LAG that is already in a
bridge and has 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 switchdev driver will have no idea that
From: Vladimir Oltean
The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
sysfs/ioctl/netlink
-> br_set_ageing_time
-> __set_ageing_time
therefore not at bridge port creation time, so:
(a) switchdev drivers have to hardcode the initial value for the address
From: Vladimir Oltean
It may happen that we have the following topology with DSA or any other
switchdev driver with LAG offload:
ip link add br0 type bridge stp_state 1
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0
ip link set swp1 master bond0
STP
From: Vladimir Oltean
Changes in v4:
- Added missing EXPORT_SYMBOL_GPL
- Using READ_ONCE(fdb->dst)
- Split patches into (a) adding the bridge helpers (b) making DSA use them
- br_mdb_replay went back to the v1 approach where it allocated memory
in atomic context
- Create
On Mon, Mar 22, 2021 at 04:04:01PM +0800, DENG Qingfang wrote:
> On Fri, Mar 19, 2021 at 6:49 PM Vladimir Oltean wrote:
> > Why would you even want to look at the source net device for forwarding?
> > I'd say that if dp->bridge_dev is NULL in the xmit function, you certa
er when a deferred switch configuration happens later.
>
> Fixes: 357f203bb3b5 ("net: dsa: keep a copy of the tagging protocol in the
> DSA switch tree")
>
> Signed-off-by: George McCollister
> ---
Reviewed-by: Vladimir Oltean
Just FYI, new lines aren't typically added between the various tags.
On Mon, Mar 22, 2021 at 03:26:50PM -0500, George McCollister wrote:
> Use a temporary variable to hold the return value from
> dsa_tag_driver_get() instead of assigning it to dst->tag_ops. Leaving
> an error value in dst->tag_ops can result in deferencing an invalid
> pointer when a deferred switch
> there is requeued skb, which has higher priority than the current
> skb.
>
> The performance for ip_forward test increases about 10% with this
> patch.
>
> Signed-off-by: Yunsheng Lin
> ---
> Hi, Vladimir and Ahmad
> Please give it a test to see if there is an
On Mon, Mar 22, 2021 at 05:30:52PM +0100, Tobias Waldekranz wrote:
> > ---
> > .../ethernet/freescale/dpaa2/dpaa2-switch.c | 4 +-
> > .../marvell/prestera/prestera_switchdev.c | 7 ++
> > .../mellanox/mlxsw/spectrum_switchdev.c | 4 +-
> > drivers/net/ethernet/mscc/ocelot_net.c
On Mon, Mar 22, 2021 at 06:07:51PM +0100, Tobias Waldekranz wrote:
> 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
> &g
On Mon, Mar 22, 2021 at 06:35:10PM +0200, Nikolay Aleksandrov wrote:
> > + hlist_for_each_entry(mp, &br->mdb_list, mdb_node) {
>
> You cannot walk over these lists without the multicast lock or RCU. RTNL is
> not
> enough because of various timers and leave messages that can alter both the
> m
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
> (i.e. bond0 or whatever) has received since, in fdb_insert, we exit
> early when
On Mon, Mar 22, 2021 at 12:17:33PM +0100, Tobias Waldekranz wrote:
> 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, rega
On Sun, Mar 21, 2021 at 07:44:19PM +0200, Vladimir Oltean wrote:
> On Sun, Mar 21, 2021 at 05:25:00PM +0100, Pavel Machek wrote:
> > Bitfield manipulation in enetc_mac_config() looks wrong. Fix
> > it. Untested.
> >
> > Signed-off-by: Pavel Machek (CIP)
> >
>
s: c76a97218dcb ("net: enetc: force the RGMII speed and duplex instead of
operating in inband mode")
Reviewed-by: Vladimir Oltean
Note that for normal operation, the bug was inconsequential, due to the
fact that we write the IF_MODE register in two stages, first in
.phylink_mac_confi
as a nice side effect that there's no more empty menu on
> configurations without DSA.
>
> 4. Kbuild will now descend into 'drivers/net/dsa' only when
>CONFIG_NET_DSA is y or m.
>
> This is safe since no objects inside this folder can be built without
> DSA
From: Vladimir Oltean
The premise of this change is that the switchdev port attributes and
objects offloaded by ocelot might have been missed when we are joining
an already existing bridge port, such as a bonding interface.
The patch pulls these switchdev attributes and objects from the bridge
From: Vladimir Oltean
Similar to the DSA situation, ocelot supports LAG offload but treats
this scenario improperly:
ip link add br0 type bridge
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0
We do the same thing as we do there, which is to simulate a
From: Vladimir Oltean
Currently this simple setup:
ip link add br0 type bridge vlan_filtering 1
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0
will not work because the bridge has created the PVID in br_add_if ->
nbp_vlan_init, and it has notif
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 will have no idea that this FDB entry is there, because it
missed the
From: Vladimir Oltean
I have udhcpcd in my system and this is configured to bring interfaces
up as soon as they are created.
I create a bridge as follows:
ip link add br0 type bridge
As soon as I create the bridge and udhcpcd brings it up, I also have
avahi which automatically starts sending
From: Vladimir Oltean
The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
sysfs/ioctl/netlink
-> br_set_ageing_time
-> __set_ageing_time
therefore not at bridge port creation time, so:
(a) drivers had to hardcode the initial value for the address agein
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
attribute is only emitted from br_mc_router_state_change.
Signed
From: Vladimir Oltean
It may happen that we have the following topology:
ip link add br0 type bridge stp_state 1
ip link add bond0 type bond
ip link set bond0 master br0
ip link set swp0 master bond0
ip link set swp1 master bond0
STP decides that it should put bond0 into the BLOCKING state
From: Vladimir Oltean
This is the same situation as for other switchdev port attributes: if we
join an already-created bridge port, such as a bond master interface,
then we can miss the initial switchdev notification emitted by the
bridge for this port.
Signed-off-by: Vladimir Oltean
Reviewed
From: Vladimir Oltean
DSA currently assumes that the bridge port starts off with this
constellation of bridge port flags:
- learning on
- unicast flooding on
- multicast flooding on
- broadcast flooding on
just by virtue of code copy-pasta from the bridge layer (new_nbp).
This was a simple
From: Vladimir Oltean
DSA can properly detect and offload this sequence of operations:
ip link add br0 type bridge
ip link add bond0 type bond
ip link set swp0 master bond0
ip link set bond0 master br0
But not this one:
ip link add br0 type bridge
ip link add bond0 type bond
ip link set bond0
From: Vladimir Oltean
This is a pretty noisy change that was broken out of the larger change
for replaying switchdev attributes and objects at bridge join time,
which is when these extack objects are actually used.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
---
Changes in v3
From: Vladimir Oltean
The objective of this series is to make LAG uppers on top of switchdev
ports work regardless of which order we link interfaces to their masters
(first make the port join the LAG, then the LAG join the bridge, or the
other way around).
There was a design decision to be made
On Fri, Mar 19, 2021 at 03:20:38PM -0700, Florian Fainelli wrote:
>
>
> On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> > From: Vladimir Oltean
> >
> > I have udhcpcd in my system and this is configured to bring interfaces
> > up as soon as they are created.
>
1 - 100 of 1688 matches
Mail list logo
