[cid] 7b49c9cf4b77a69f03297f515c89e94f21c9b1c0
ARM: dts: qcom: change labels to lower-case
DTS coding style expects labels to be lowercase. No functional impact.
Verified with comparing decompiled DTB (dtx_diff and fdtdump+diff).
Signed-off-by: Hans Ulli Kroll <linux@ulli-kroll.de>
Signed-off-by: Lars Gierth <larsg@systemli.org>
Link: https://github.com/openwrt/openwrt/pull/25854
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
The prefix row placement is common to RTL839x and RTL930x, but where an
IPv6 entry sits is not: an RTL839x PIE rule matches a whole IPv6
destination in any row, while an RTL930x entry spans three rows and may
only start on two rows of every eight. otto_l3_v6_row() and
otto_l3_v6_slot() chose between the two layouts through use_l3_tables,
which says how a family routes, not how its table is laid out.
Give the families v6_slot_to_row() and v6_row_to_slot() and move each
layout next to its row mover. Ordering, insertion, compaction and the
capacity and IPv4/IPv6 collision checks stay common, and keep calling
the same two helpers, which now ask the family. The common code calls
them only for a family with a row mover.
The formulas move unchanged. Built on the host from l3.c as it is, the
placement code before and after this change maps every slot and row of
both layouts alike, and runs 160000 random IPv4 and IPv6 insertions and
removals, past a full table on both families, with the same rows and
the same moves; a one-line mutation planted in each of the four
callbacks makes the results differ. On an HPE 1920-48G (RTL8393) an
IPv6 test round passes 20 of 20 checks, among them a /48 and a /64
inserted in both orders and IPv4 and IPv6 routes side by side, the
routes of those checks forwarded in hardware to the right gateway.
RTL930x is compile-tested only.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25868
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Commit 4071398b13 replaced $(VERSION_DIST) in the netgear-dni and
netgear-encrypted-factory recipes with $(shell cat $(VERSION_DIST) | sed
...) to turn whitespace into dashes. VERSION_DIST holds the distribution
name such as "OpenWrt" and not a file name, so cat fails with "No such
file or directory" and the expansion is always empty.
The change was meant to let a distribution name with a space, such as
"ColVisTec AG", pass through the argument parsing of
netgear-encrypted-factory.py as "ColVisTec-AG". What it produced instead
was an empty string for every distribution name, including the one it
was written for. The build error went away only because an empty string
contains no whitespace.
Since then, the DNI header of the Netgear images carries
"version:V.r12345" instead of "version:VOpenWrt.r12345", and the
encrypted factory images get "V1.0.0.0..r12345" with an empty field
between two dots instead of "V1.0.0.0.OpenWrt.r12345".
The distribution name has been part of the Netgear version string since
commit 6d2fa1c896 added the first WNDR3700 factory image in 2009, and
the encrypted factory recipe used it from its introduction in commit
efca76ffce.
Use $(subst $(space),-,$(VERSION_DIST)) instead, which restores the
distribution name and still replaces spaces with dashes as intended.
Fixes: 4071398b13 ("build: escape whitespaces in VERSION_DIST for Netgear images")
Signed-off-by: Grische <github@grische.xyz>
Assisted-by: Claude:claude-opus-5-5
Link: https://github.com/openwrt/openwrt/pull/25674
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Herospeed RV1126 IMX415 "Base" is an IP camera built on a Rockchip
38x38 V10 EMMC DDR3 board, which is also found in cameras of other
makes and is therefore described by a separate dtsi. The stock firmware
identifies itself as ONVIF manufacturer "HeroSpeed", firmware family
RV1126_IMX415_BASE. This adds the 32-bit armv7 subtarget for the
Cortex-A7 based RV11xx SoCs. The camera keeps its stock U-Boot, which
boots an Android boot image from one of two boot/system slots.
Hardware
--------
SoC: Rockchip RV1126, 4x Cortex-A7
RAM: 1 GiB DDR3
Flash: eMMC, 8 GB class, two boot/system slots
Ethernet: 1x 10/100 Mbit/s, JL1101 PHY on RMII
Sensor: Sony IMX415, 4 lane MIPI CSI-2
RTC: PCF8563
LEDs: white illumination LEDs on one PWM output (V4L2 flash)
Buttons: none
UART: 1.8 V TTL on UART2, 1500000 baud 8N1, 90-degree JST-SH connector
at the bottom edge of the board, facing the edge and hidden underneath
the MIPI CSI cable
Power: PoE (IEEE 802.3af) or 12 V 1 A DC through the barrel connector
on the cable whip
Installation
------------
1. Open the web interface of the stock firmware (192.168.1.168 by
default) and log in as admin.
2. Upload openwrt-rockchip-armv7-herospeed_rv1126-imx415-squashfs-
factory-RV1126_IMX415.fls on the firmware upgrade page.
3. The camera reboots into OpenWrt at 192.168.1.1.
Later upgrades use the sysupgrade image, which is written to the
inactive slot. The stock firmware can be restored from OpenWrt with
"sysupgrade -F -n" and the original .FLS file.
MAC address
-----------
eth0 uses the label MAC, stored as MAC=xx:xx:xx:xx:xx:xx in net.conf on
the ext4 "param" partition. U-Boot passes a different, derived address
to Linux, which is replaced by the stored one.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Add RV1126 support (USB2 PHY and DWC3, TSADC, clocks, I2C and SPI,
cpufreq, I2S and PDM, VICAP, MIPI CSI-2 D-PHY, VPU, RGA, hwrng) and
describe the SoC in rv1126.dtsi. Import and rewrite the unmerged
crypto driver for RK3568 and RK3588 by Corentin Labbe (AES, hashes);
its RK3568 and RK3588 support is untested. Add a newly written driver
for flash LEDs driven by a PWM channel.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Backport the pixel clock sampling mode defines of the video-interfaces
dt-bindings header, which the rk3568 vicap binding example already
uses. The Rockchip RV1126 capture nodes refer to the same header.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
mkrkboot builds the Android boot image, with the Rockchip resource
image holding the device tree, that the U-Boot of the Rockchip RV11xx
camera SoCs boots.
mkhsfls packs the .FLS container accepted by the web interface of
Herospeed cameras.
Both are used by the image recipes of the rockchip/armv7 subtarget.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The pci and pcie features and the Image kernel target describe the
64-bit RK33xx/RK35xx boards, not the Rockchip family as a whole. Set
them in the armv8 target.mk so that a 32-bit ARM subtarget can build a
zImage and does not advertise PCIe.
The feature set and kernel targets of armv8 stay as they were.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The use map counts the routes that forward through an L2 unicast entry
in seven bits. At 127 the count stops, and an entry that got there is
never released: when its routes are gone it keeps its next hop flag
until the switch restarts. RTL930x takes 512 prefix and 1536 host
routes, so more than 126 through one gateway is an ordinary table.
Give the count fifteen bits, more than the routes of any family. The
map grows from one to two bytes per entry.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Quinn O'Shea <qoshea@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25859
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
A route with no gateway keeps the unspecified address where its gateway
would be, 0.0.0.0 or ::, and so does the route of each address of the
switch. Their rows trap to the CPU. The kernel accepts a neighbour at
that address when one is added by hand, and otto_l3_nexthop_update(),
which matches a neighbour on the gateway and the device recorded for
each route, takes it for the gateway of such routes and can turn their
rows into forwarding ones. Leave such a neighbour alone: it is the
gateway of no route.
HPE 1920-48G (RTL8393), host B on VLAN 3, 10.99.0.0/16 dev switch.3,
and
ip neigh add 0.0.0.0 lladdr <MAC of host B> dev switch.3 nud permanent
Without the change the row of 10.99.0.0/16 forwarded 8 of 8 echo
requests from another VLAN to host B with TTL 63, none reached the CPU,
and the rows of the switch's addresses and on-link prefixes on switch.3
turned to forwarding as well: a host on another VLAN got no answer from
10.91.3.1, 0 of 3. With :: on IPv6 the trap rows of fd00:90:3::1/128,
fd00:90:3::/64 and 2001:db8:99::/48 went through the same update and
took a packet counter each, but kept trapping here.
With the change the neighbour event still arrives and changes nothing:
the rows keep trapping and take no counter, the 8 echo requests reach
the CPU, and the switch answers on 10.91.3.1 and fd00:90:3::1, 3 of 3.
A route through a gateway, measured before the neighbour was added,
forwards in hardware on both, 8 of 8 with TTL and hop limit 63.
RTL930x is compile-tested only; families without an L3 setup never
queue the neighbour event.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25863
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Manually adjusted symbols:
- SOC_SAMA7D65: SAMA7D65 family
- PAGE_BLOCK_MAX_ORDER: Page Block Order Upper Limit
- SPI_POLARFIRE_SOC: Microchip FPGA SPI controllers
All other kernel config symbols are automatically refreshed by
`make kernel_oldconfig`.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/25436
Signed-off-by: Robert Marko <robimarko@gmail.com>
Two symbols needed input, the respective default was picked:
- CONFIG_PAGE_BLOCK_MAX_ORDER, default 10
- CONFIG_FRAME_WARN, but was dropped by kernel oldconfig
The other symbol changes are automatic.
Signed-off-by: Lars Gierth <larsg@systemli.org>
Link: https://github.com/openwrt/openwrt/pull/25421
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL839x route dump reads a ROUTING row back with
otto_l3_839x_nexthop_read(), which fills a whole route to hand over a
gateway MAC and a switch MAC entry. Read DMAC entries back the way they
are written instead: get_dmac() fills the struct otto_l3_dmac that
set_dmac() takes. RTL839x decodes the gateway MAC and SW_MAC_IDX from
the row; RTL930x reads the MAC from its egress MAC table and leaves
smac_id at 0, since its egress interfaces name the source MAC. A read
that fails returns its error, and the dump prints "-" for it.
Only the RTL839x dump uses it; nothing else changes. On an HPE 1920-48G
(RTL8393) it reads back the gateway MAC with MAC_ID 1 for a route out of
a device with a MAC of its own, and 0 for one out of the switch MAC.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25852
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Common code reaches the source MACs of the two families in two ways:
RTL930x callers add L3_EGRESS_DMACS to an index of its egress MAC
table, which holds destination and source MACs alike, while RTL839x
writes its switch MAC entries through set_switch_mac(). Give both the
same pair, get_smac() and set_smac(), on the index of the source MAC
entry: RTL839x reads and writes ROUTING_SA_CTRL, RTL930x adds
L3_EGRESS_DMACS itself, so the layout of its table stays in the RTL930x
code.
The accessors report a failed table access, and the callers act on it
where they can. An egress interface whose source MAC cannot be written
is not taken, and its route is not offloaded; nor is a switch MAC entry
that cannot be written, and its route keeps to the CPU. The allocator
skips a source MAC it cannot read: it is neither free nor a match. An
interface that cannot take its device's new MAC keeps the old one, as
when none is free. A source MAC that cannot be cleared when its last
route goes, or at RTL930x setup, is logged; a failed setup would fail
the whole switch probe. The RTL930x next hop dump prints "-" for one it
cannot read. Before, all of these were ignored. The egress interface
allocator returns -ENOSPC rather than -1 when none is free, as
otto_l3_dmac_get() and otto_l3_switch_mac_get() do.
RTL839x writes registers, which cannot fail, so it behaves as before.
Tested on an HPE 1920-48G (RTL8393): a VLAN device with a MAC of its
own takes switch MAC entry 1, frames to it are routed in hardware, and
the entry is freed when the routes holding it go. RTL930x
compile-tested only.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25852
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The common L3 code tells the RTL839x source MAC model apart by whether
the family sets set_switch_mac: there a route takes the source MAC
entry of the device it goes out of, its DMAC entry names that entry,
and the entries are also the MACs whose frames are routed. Once both
families reach their source MACs through the same operations, that
test no longer tells them apart.
Name the model with smac_per_route, set for RTL839x, and test that
wherever the code chose it by set_switch_mac. No functional change:
RTL839x sets both, RTL838x, RTL930x and RTL931x neither.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25852
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
VLAN support is broken on MT7530/MT7531 switches (seen on the ASUS
ZenWiFi BT8): after a VLAN-aware bridge is destroyed, VLAN-unaware
bridges lose connectivity, and untagged PVID traffic does not reach
the bridge VLAN upper interface (br-lan.<vid>).
Backport two fixes from Linux v7.1:
- 2c4c76cacc9d ("net: dsa: mt7530: fix CPU port VLAN not being reset
to unaware")
- 4cb3cd670b2a ("net: dsa: mt7530: untag VLAN-aware bridge PVID")
Both patches apply cleanly to 6.18 and were refreshed with
make target/linux/refresh.
Fixes: https://github.com/openwrt/openwrt/issues/18576
Signed-off-by: Marc Strämke <marcstraemke@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25247
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
A flower rule whose only action is a byte rate police is programmed as
the rate limiter of the port without a look at what the rule matches. A
rule that polices broadcast frames to 10 Mbit/s limits all traffic of
the port to 10 Mbit/s.
Deleting has the matching defect: the delete callback also arrives for
rules that never made it into the hardware, and any of them that is not
a PIE rule switches the limiter of the port off, while the rule that
set the limiter up is still reported as offloaded.
Program the limiter only for a rule that reaches every frame of the
port: in chain 0, for all protocols and without match. Remember which
rule that was and remove the limiter only when this rule goes. Any
other police rule is no longer offloaded.
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Quinn O'Shea <qoshea@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25845
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The wdr4300.dtsi USB port feeds a 4-port GL850G hub, so the LED trigger
sources are its four downstream ports. Override usb0 to drop the generic
trigger node and declare the hub with its device ID, mirroring the NEC
aterm boards.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25340
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Pi-WiFi4 USB port feeds a 4-port GL850G hub, so the LED trigger
sources are its four downstream ports. Override usb0 to drop the generic
trigger node and declare the hub with its device ID, mirroring the NEC
aterm boards.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25340
Signed-off-by: Robert Marko <robimarko@gmail.com>
The &usb override re-declares hub_port/@address-cells/#size-cells with
values identical to the ones inherited from ar934x.dtsi, so it has no
effect. Drop it and leave only the status change.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25340
Signed-off-by: Robert Marko <robimarko@gmail.com>
Dynamic SGMII PHY links may remain software-forced, which prevents PCS
state changes from generating MAC link interrupts. Enable phylink PCS
polling for in-band SGMII so links recover after the PCS settles
following a mode change.
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
RTL931x controls forced link, speed, duplex, and flow control with
separate enable bits. Describe the register layout and provide a MAC
link-state source selector so the common RTL93xx callbacks can manage
its force-mode transitions.
This supports fixed links, CPU ports, and dynamic SFP PHYs while
leaving statically described PHY links and direct PCS links
hardware-controlled. Dynamic SGMII and out-of-band PHYs remain forced,
while dynamic USXGMII PHYs return to PCS-controlled state after the
force pulse.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Use separate RTL83xx and RTL93xx link-down callbacks so their
family-specific force-mode handling can evolve independently.
The RTL83xx callback retains the legacy force-mode clearing behavior.
The RTL93xx callback preserves force mode for forced RTL930x links and
keeps PCS source selection with the corresponding link-down handling.
This also prepares the common RTL93xx path for RTL931x support.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>
Move the family-specific MAC force mode register layout into the switch
configuration. This removes family checks from the RTL83xx link-up path
and converts RTL930x handling to the same field descriptions.
Describe link-state and flow-control force enables separately along with
the fields used to construct resolved MAC state. This allows phylink's
resolved pause settings to remain forced when link state is controlled by
hardware. Add the initial RTL931x link-force description in preparation
for later RTL931x support.
Assisted-by: ChatGPT (OpenAI GPT-5.6 Sol)
Link: https://github.com/openwrt/openwrt/pull/25118
Signed-off-by: Jonas Jelonek <jonas@jonasjelonek.de>