<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include/soc, branch rpi-mipi</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include/soc?h=rpi-mipi</id>
<link rel='self' href='https://git.amat.us/linux/atom/include/soc?h=rpi-mipi'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2025-05-06T13:14:05Z</updated>
<entry>
<title>Merge remote-tracking branch 'stable/linux-6.12.y' into rpi-6.12.y</title>
<updated>2025-05-06T13:14:05Z</updated>
<author>
<name>Dom Cobley</name>
<email>popcornmix@gmail.com</email>
</author>
<published>2025-05-06T13:14:05Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3bcb24f746a219b16827228cc9f801fcf5751a0e'/>
<id>urn:sha1:3bcb24f746a219b16827228cc9f801fcf5751a0e</id>
<content type='text'>
</content>
</entry>
<entry>
<title>soc: qcom: ice: introduce devm_of_qcom_ice_get</title>
<updated>2025-05-02T05:58:52Z</updated>
<author>
<name>Tudor Ambarus</name>
<email>tudor.ambarus@linaro.org</email>
</author>
<published>2025-01-17T14:18:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=311a651fbb780d62b5b6d3e56e1287cee5491739'/>
<id>urn:sha1:311a651fbb780d62b5b6d3e56e1287cee5491739</id>
<content type='text'>
[ Upstream commit 1c13d6060d612601a61423f2e8fbf9e48126acca ]

Callers of of_qcom_ice_get() leak the device reference taken by
of_find_device_by_node(). Introduce devm variant for of_qcom_ice_get().
Existing consumers need the ICE instance for the entire life of their
device, thus exporting qcom_ice_put() is not required.

Signed-off-by: Tudor Ambarus &lt;tudor.ambarus@linaro.org&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@linaro.org&gt;
Reviewed-by: Abel Vesa &lt;abel.vesa@linaro.org&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Link: https://lore.kernel.org/r/20250117-qcom-ice-fix-dev-leak-v2-1-1ffa5b6884cb@linaro.org
Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;
Stable-dep-of: cbef7442fba5 ("mmc: sdhci-msm: fix dev reference leaked through of_qcom_ice_get")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>raspberrypi-firmware: Add the RPI firmware UART APIs</title>
<updated>2025-03-25T12:27:43Z</updated>
<author>
<name>Tim Gover</name>
<email>tim.gover@raspberrypi.com</email>
</author>
<published>2024-11-01T19:42:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=34cab32a6dea240c0527f9eff3d902184b0b3b56'/>
<id>urn:sha1:34cab32a6dea240c0527f9eff3d902184b0b3b56</id>
<content type='text'>
Add VideoCore mailbox definitions for the new RPi firmware UART.

Signed-off-by: Tim Gover &lt;tim.gover@raspberrypi.com&gt;
</content>
</entry>
<entry>
<title>clk-raspberrypi: Add ISP to exported clocks</title>
<updated>2025-03-25T12:26:54Z</updated>
<author>
<name>Dom Cobley</name>
<email>popcornmix@gmail.com</email>
</author>
<published>2022-04-12T19:07:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5a021982efab6c458dea55c1a5405f6e33f6fc11'/>
<id>urn:sha1:5a021982efab6c458dea55c1a5405f6e33f6fc11</id>
<content type='text'>
Signed-off-by: Dom Cobley &lt;popcornmix@gmail.com&gt;

clk-raspberrypi: Enable minimize for all firmware clocks

Signed-off-by: Dom Cobley &lt;popcornmix@gmail.com&gt;

clk: bcm: rpi: Add disp clock

BCM2712 has an extra clock exposed by the firmware called DISP, and used
by (at least) the HVS. Let's add it to the list of clocks to register in
Linux.

Signed-off-by: Maxime Ripard &lt;maxime@cerno.tech&gt;

clk: bcm: rpi: Add the BCM283x pixel clock.

The clk-bcm2835 handling of the pixel clock does not function
correctly when the HDMI power domain is disabled.

The firmware supports it correctly, so add it to the
firmware clock driver.

Signed-off-by: Dave Stevenson &lt;dave.stevenson@raspberrypi.com&gt;
</content>
</entry>
<entry>
<title>raspberrypi-firmware: Update mailbox commands</title>
<updated>2025-03-25T12:26:53Z</updated>
<author>
<name>Dom Cobley</name>
<email>popcornmix@gmail.com</email>
</author>
<published>2022-04-07T17:23:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=cbd5557e62040b84df2f708db51d3d90ad71ae2e'/>
<id>urn:sha1:cbd5557e62040b84df2f708db51d3d90ad71ae2e</id>
<content type='text'>
Signed-off-by: Dom Cobley &lt;popcornmix@gmail.com&gt;
</content>
</entry>
<entry>
<title>net: mscc: ocelot: be resilient to loss of PTP packets during transmission</title>
<updated>2024-12-19T17:13:14Z</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2024-12-05T14:55:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=266ac61e59119a9d4c74fe2d35341e7babb6b68a'/>
<id>urn:sha1:266ac61e59119a9d4c74fe2d35341e7babb6b68a</id>
<content type='text'>
[ Upstream commit b454abfab52543c44b581afc807b9f97fc1e7a3a ]

The Felix DSA driver presents unique challenges that make the simplistic
ocelot PTP TX timestamping procedure unreliable: any transmitted packet
may be lost in hardware before it ever leaves our local system.

This may happen because there is congestion on the DSA conduit, the
switch CPU port or even user port (Qdiscs like taprio may delay packets
indefinitely by design).

The technical problem is that the kernel, i.e. ocelot_port_add_txtstamp_skb(),
runs out of timestamp IDs eventually, because it never detects that
packets are lost, and keeps the IDs of the lost packets on hold
indefinitely. The manifestation of the issue once the entire timestamp
ID range becomes busy looks like this in dmesg:

mscc_felix 0000:00:00.5: port 0 delivering skb without TX timestamp
mscc_felix 0000:00:00.5: port 1 delivering skb without TX timestamp

At the surface level, we need a timeout timer so that the kernel knows a
timestamp ID is available again. But there is a deeper problem with the
implementation, which is the monotonically increasing ocelot_port-&gt;ts_id.
In the presence of packet loss, it will be impossible to detect that and
reuse one of the holes created in the range of free timestamp IDs.

What we actually need is a bitmap of 63 timestamp IDs tracking which one
is available. That is able to use up holes caused by packet loss, but
also gives us a unique opportunity to not implement an actual timer_list
for the timeout timer (very complicated in terms of locking).

We could only declare a timestamp ID stale on demand (lazily), aka when
there's no other timestamp ID available. There are pros and cons to this
approach: the implementation is much more simple than per-packet timers
would be, but most of the stale packets would be quasi-leaked - not
really leaked, but blocked in driver memory, since this algorithm sees
no reason to free them.

An improved technique would be to check for stale timestamp IDs every
time we allocate a new one. Assuming a constant flux of PTP packets,
this avoids stale packets being blocked in memory, but of course,
packets lost at the end of the flux are still blocked until the flux
resumes (nobody left to kick them out).

Since implementing per-packet timers is way too complicated, this should
be good enough.

Testing procedure:

Persistently block traffic class 5 and try to run PTP on it:
$ tc qdisc replace dev swp3 parent root taprio num_tc 8 \
	map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
	base-time 0 sched-entry S 0xdf 100000 flags 0x2
[  126.948141] mscc_felix 0000:00:00.5: port 3 tc 5 min gate length 0 ns not enough for max frame size 1526 at 1000 Mbps, dropping frames over 1 octets including FCS
$ ptp4l -i swp3 -2 -P -m --socket_priority 5 --fault_reset_interval ASAP --logSyncInterval -3
ptp4l[70.351]: port 1 (swp3): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[70.354]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[70.358]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
[   70.394583] mscc_felix 0000:00:00.5: port 3 timestamp id 0
ptp4l[70.406]: timed out while polling for tx timestamp
ptp4l[70.406]: increasing tx_timestamp_timeout or increasing kworker priority may correct this issue, but a driver bug likely causes it
ptp4l[70.406]: port 1 (swp3): send peer delay response failed
ptp4l[70.407]: port 1 (swp3): clearing fault immediately
ptp4l[70.952]: port 1 (swp3): new foreign master d858d7.fffe.00ca6d-1
[   71.394858] mscc_felix 0000:00:00.5: port 3 timestamp id 1
ptp4l[71.400]: timed out while polling for tx timestamp
ptp4l[71.400]: increasing tx_timestamp_timeout or increasing kworker priority may correct this issue, but a driver bug likely causes it
ptp4l[71.401]: port 1 (swp3): send peer delay response failed
ptp4l[71.401]: port 1 (swp3): clearing fault immediately
[   72.393616] mscc_felix 0000:00:00.5: port 3 timestamp id 2
ptp4l[72.401]: timed out while polling for tx timestamp
ptp4l[72.402]: increasing tx_timestamp_timeout or increasing kworker priority may correct this issue, but a driver bug likely causes it
ptp4l[72.402]: port 1 (swp3): send peer delay response failed
ptp4l[72.402]: port 1 (swp3): clearing fault immediately
ptp4l[72.952]: port 1 (swp3): new foreign master d858d7.fffe.00ca6d-1
[   73.395291] mscc_felix 0000:00:00.5: port 3 timestamp id 3
ptp4l[73.400]: timed out while polling for tx timestamp
ptp4l[73.400]: increasing tx_timestamp_timeout or increasing kworker priority may correct this issue, but a driver bug likely causes it
ptp4l[73.400]: port 1 (swp3): send peer delay response failed
ptp4l[73.400]: port 1 (swp3): clearing fault immediately
[   74.394282] mscc_felix 0000:00:00.5: port 3 timestamp id 4
ptp4l[74.400]: timed out while polling for tx timestamp
ptp4l[74.401]: increasing tx_timestamp_timeout or increasing kworker priority may correct this issue, but a driver bug likely causes it
ptp4l[74.401]: port 1 (swp3): send peer delay response failed
ptp4l[74.401]: port 1 (swp3): clearing fault immediately
ptp4l[74.953]: port 1 (swp3): new foreign master d858d7.fffe.00ca6d-1
[   75.396830] mscc_felix 0000:00:00.5: port 3 invalidating stale timestamp ID 0 which seems lost
[   75.405760] mscc_felix 0000:00:00.5: port 3 timestamp id 0
ptp4l[75.410]: timed out while polling for tx timestamp
ptp4l[75.411]: increasing tx_timestamp_timeout or increasing kworker priority may correct this issue, but a driver bug likely causes it
ptp4l[75.411]: port 1 (swp3): send peer delay response failed
ptp4l[75.411]: port 1 (swp3): clearing fault immediately
(...)

Remove the blocking condition and see that the port recovers:
$ same tc command as above, but use "sched-entry S 0xff" instead
$ same ptp4l command as above
ptp4l[99.489]: port 1 (swp3): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[99.490]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[99.492]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
[  100.403768] mscc_felix 0000:00:00.5: port 3 invalidating stale timestamp ID 0 which seems lost
[  100.412545] mscc_felix 0000:00:00.5: port 3 invalidating stale timestamp ID 1 which seems lost
[  100.421283] mscc_felix 0000:00:00.5: port 3 invalidating stale timestamp ID 2 which seems lost
[  100.430015] mscc_felix 0000:00:00.5: port 3 invalidating stale timestamp ID 3 which seems lost
[  100.438744] mscc_felix 0000:00:00.5: port 3 invalidating stale timestamp ID 4 which seems lost
[  100.447470] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  100.505919] mscc_felix 0000:00:00.5: port 3 timestamp id 0
ptp4l[100.963]: port 1 (swp3): new foreign master d858d7.fffe.00ca6d-1
[  101.405077] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  101.507953] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  102.405405] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  102.509391] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  103.406003] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  103.510011] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  104.405601] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  104.510624] mscc_felix 0000:00:00.5: port 3 timestamp id 0
ptp4l[104.965]: selected best master clock d858d7.fffe.00ca6d
ptp4l[104.966]: port 1 (swp3): assuming the grand master role
ptp4l[104.967]: port 1 (swp3): LISTENING to GRAND_MASTER on RS_GRAND_MASTER
[  105.106201] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  105.232420] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  105.359001] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  105.405500] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  105.485356] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  105.511220] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  105.610938] mscc_felix 0000:00:00.5: port 3 timestamp id 0
[  105.737237] mscc_felix 0000:00:00.5: port 3 timestamp id 0
(...)

Notice that in this new usage pattern, a non-congested port should
basically use timestamp ID 0 all the time, progressing to higher numbers
only if there are unacknowledged timestamps in flight. Compare this to
the old usage, where the timestamp ID used to monotonically increase
modulo OCELOT_MAX_PTP_ID.

In terms of implementation, this simplifies the bookkeeping of the
ocelot_port :: ts_id and ptp_skbs_in_flight. Since we need to traverse
the list of two-step timestampable skbs for each new packet anyway, the
information can already be computed and does not need to be stored.
Also, ocelot_port-&gt;tx_skbs is always accessed under the switch-wide
ocelot-&gt;ts_id_lock IRQ-unsafe spinlock, so we don't need the skb queue's
lock and can use the unlocked primitives safely.

This problem was actually detected using the tc-taprio offload, and is
causing trouble in TSN scenarios, which Felix (NXP LS1028A / VSC9959)
supports but Ocelot (VSC7514) does not. Thus, I've selected the commit
to blame as the one adding initial timestamping support for the Felix
switch.

Fixes: c0bcf537667c ("net: dsa: ocelot: add hardware timestamping support for Felix")
Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Link: https://patch.msgid.link/20241205145519.1236778-5-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'soc-drivers-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc</title>
<updated>2024-09-17T08:48:09Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-09-17T08:48:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b8979c6b4d0d1b36e94f5bc483fd86e38107e554'/>
<id>urn:sha1:b8979c6b4d0d1b36e94f5bc483fd86e38107e554</id>
<content type='text'>
Pull SoC driver updates from Arnd Bergmann:
 "The driver updates seem larger this time around, with changes is many
  of the SoC specific drivers, both the custom drivers/soc ones and the
  closely related subsystems (memory, bus, firmware, reset, ...).

  The at91 platform gains support for sam9x7 chips in the soc and power
  management code. This is the latest variant of one of the oldest still
  supported SoC families, using the ARM9 (ARMv5) core.

  As usual, the qualcomm snapdragon platform gets a ton of updates in
  many of their drivers to add more features and additional SoC support.
  Most of these are somewhat firmware related as the platform has a
  number of firmware based interfaces to the kernel. A notable addition
  here is the inclusion of trace events to two of these drivers.

  Herve Codina and Christophe Leroy are now sending updates for
  drivers/soc/fsl/ code through the SoC tree, this contains both PowerPC
  and Arm specific platforms and has previously been problematic to
  maintain. The first update here contains support for newer PowerPC
  variants and some cleanups.

  The turris mox firmware driver has a number of updates, mostly
  cleanups.

  The Arm SCMI firmware driver gets a major rework to modularize the
  existing code into separately loadable drivers for the various
  transports, the addition of custom NXP i.MX9 interfaces and a number
  of smaller updates.

  The Arm FF-A firmware driver gets a feature update to support the v1.2
  version of the specification.

  The reset controller drivers have some smaller cleanups and a newly
  added driver for the Intel/Mobileye EyeQ5/EyeQ6 MIPS SoCs.

  The memory controller drivers get some cleanups and refactoring for
  Tegra, TI, Freescale/NXP and a couple more platforms.

  Finally there are lots of minor updates to firmware (raspberry pi,
  tegra, imx), bus (sunxi, omap, tegra) and soc (rockchips, tegra,
  amlogic, mediatek) drivers and their DT bindings"

* tag 'soc-drivers-6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (212 commits)
  firmware: imx: remove duplicate scmi_imx_misc_ctrl_get()
  platform: cznic: turris-omnia-mcu: Fix error check in omnia_mcu_register_trng()
  bus: sunxi-rsb: Simplify code with dev_err_probe()
  soc: fsl: qe: ucc: Export ucc_mux_set_grant_tsa_bkpt
  soc: fsl: cpm1: qmc: Fix dependency on fsl_soc.h
  dt-bindings: arm: rockchip: Add rk3576 compatible string to pmu.yaml
  soc: fsl: qbman: Remove redundant warnings
  soc: fsl: qbman: Use iommu_paging_domain_alloc()
  MAINTAINERS: Add QE files related to the Freescale QMC controller
  soc: fsl: cpm1: qmc: Handle QUICC Engine (QE) soft-qmc firmware
  soc: fsl: cpm1: qmc: Add support for QUICC Engine (QE) implementation
  soc: fsl: qe: Add missing PUSHSCHED command
  soc: fsl: qe: Add resource-managed muram allocators
  soc: fsl: cpm1: qmc: Introduce qmc_version
  soc: fsl: cpm1: qmc: Rename SCC_GSMRL_MODE_QMC
  soc: fsl: cpm1: qmc: Handle RPACK initialization
  soc: fsl: cpm1: qmc: Rename qmc_chan_command()
  soc: fsl: cpm1: qmc: Introduce qmc_{init,exit}_xcc() and their CPM1 version
  soc: fsl: cpm1: qmc: Introduce qmc_init_resource() and its CPM1 version
  soc: fsl: cpm1: qmc: Re-order probe() operations
  ...
</content>
</entry>
<entry>
<title>soc: fsl: qe: Add missing PUSHSCHED command</title>
<updated>2024-09-03T05:49:20Z</updated>
<author>
<name>Herve Codina</name>
<email>herve.codina@bootlin.com</email>
</author>
<published>2024-08-08T07:11:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f68cd02d51a65594341168f03f7962e9d9540726'/>
<id>urn:sha1:f68cd02d51a65594341168f03f7962e9d9540726</id>
<content type='text'>
The PUSHSCHED command is missing in the QE header file.

This command is supported on MPC8321 and is used to modify the start
address for the task running on a given peripheral. It is needed for the
QMC in order to perform the re-initialization procedure and so, ensure
the correct UCC setup in that case.

Simply add the missing command in the commands list available in the QE
header file.

Signed-off-by: Herve Codina &lt;herve.codina@bootlin.com&gt;
Reviewed-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Link: https://lore.kernel.org/r/20240808071132.149251-34-herve.codina@bootlin.com
Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
</content>
</entry>
<entry>
<title>soc: fsl: qe: Add resource-managed muram allocators</title>
<updated>2024-09-03T05:49:20Z</updated>
<author>
<name>Herve Codina</name>
<email>herve.codina@bootlin.com</email>
</author>
<published>2024-08-08T07:11:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c6f39c7c165fce8fe1a41327da02dcca0a3cac25'/>
<id>urn:sha1:c6f39c7c165fce8fe1a41327da02dcca0a3cac25</id>
<content type='text'>
Introduce devm_cpm_muram_alloc() and devm_cpm_muram_alloc_fixed(), the
resource-managed version of cpm_muram_alloc and cpm_muram_alloc_fixed().

These resource-managed versions simplify the user avoiding the need to
call cpm_muram_free(). Indeed, the allocated area returned by these
functions will be automatically freed on driver detach.

Signed-off-by: Herve Codina &lt;herve.codina@bootlin.com&gt;
Reviewed-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
Link: https://lore.kernel.org/r/20240808071132.149251-33-herve.codina@bootlin.com
Signed-off-by: Christophe Leroy &lt;christophe.leroy@csgroup.eu&gt;
</content>
</entry>
<entry>
<title>net: mscc: ocelot: treat 802.1ad tagged traffic as 802.1Q-untagged</title>
<updated>2024-08-16T08:59:32Z</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2024-08-15T00:07:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=36dd1141be70b5966906919714dc504a24c65ddf'/>
<id>urn:sha1:36dd1141be70b5966906919714dc504a24c65ddf</id>
<content type='text'>
I was revisiting the topic of 802.1ad treatment in the Ocelot switch [0]
and realized that not only is its basic VLAN classification pipeline
improper for offloading vlan_protocol 802.1ad bridges, but also improper
for offloading regular 802.1Q bridges already.

Namely, 802.1ad-tagged traffic should be treated as VLAN-untagged by
bridged ports, but this switch treats it as if it was 802.1Q-tagged with
the same VID as in the 802.1ad header. This is markedly different to
what the Linux bridge expects; see the "other_tpid()" function in
tools/testing/selftests/net/forwarding/bridge_vlan_aware.sh.

An idea came to me that the VCAP IS1 TCAM is more powerful than I'm
giving it credit for, and that it actually overwrites the classified VID
before the VLAN Table lookup takes place. In other words, it can be
used even to save a packet from being dropped on ingress due to VLAN
membership.

Add a sophisticated TCAM rule hardcoded into the driver to force the
switch to behave like a Linux bridge with vlan_filtering 1 vlan_protocol
802.1Q.

Regarding the lifetime of the filter: eventually the bridge will
disappear, and vlan_filtering on the port will be restored to 0 for
standalone mode. Then the filter will be deleted.

[0]: https://lore.kernel.org/netdev/20201009122947.nvhye4hvcha3tljh@skbuf/

Fixes: 7142529f1688 ("net: mscc: ocelot: add VLAN filtering")
Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
