This fixes a previous commit for Sophos XG 210r3 which was missing
board_name mapping and adds support for the SG related version and the
XG/SG 230r2 which is the same hardware with a faster processor.
Sophos board_name mapping was modified to support all Sophos
SG/XG devices.
Sophos SG/XG 210r3 and SG/XG 230r2 are rackmounted x86 based firewall
with 6 RJ-45 gigabit ethernet ports (eth0-5) and 2 SFP gigabit ethernet
ports (eth6, eth7) all running Intel NICs supported by igb driver. The 210r3
and 230r2 only differ in the processor used. This board update maps
eth1 (marked as WAN) as wan and eth0 and eth2-5 as lan. Leaving the
two SFP ports unmapped.
Fixes: 4880e8e338 ("x86: add board mapping for Sophos XG 210r3")
Signed-off-by: Raylynn Knight <rayknight@me.com>
Link: https://github.com/openwrt/openwrt/pull/21959
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add dependencies for Turris MOX board modules directly as
DEVICE_PACKAGES. (So that users don't have to add them manually.)
The device uses an SD card for primary storage so space shouldn't be an
issue.
Signed-off-by: Tomáš Macholda <tomas.macholda@nic.cz>
Link: https://github.com/openwrt/openwrt/pull/21151
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
RIPE Atlas Probe v5 is a network measurement device based on Turris MOX.
u-boot bootscript supports booting both from the original Turris BTRFS
layout and default OpenWrt ext4 boot + root partition layout.
Specifications:
* SoC: Marvell ARMADA 3720
* RAM: 512 MiB, DDR3
* eMMC: 4G
* Ethernet: 1x 1GbE
MAC:
LAN MAC: label on board
Flash instructions:
* For using the default ext4 layout, boot into a live system using
tftpboot in u-boot and flash an OpenWrt SD image onto /dev/mmcblk0.
* For the Turris layout, put the new rootfs into subvolume '@', not
forgetting to add Image, device tree, and boot.scr to /boot.
Misc:
* USB connection is only for power. For UART access use the pin header:
1: GND
2: +1.8V
5: TX
6: RX
* Flashing the image onto Turris Shield won't work. Use Turris MOX image
instead.
Signed-off-by: Tomáš Macholda <tomas.macholda@nic.cz>
Link: https://github.com/openwrt/openwrt/pull/20031
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This adds support for the Gemini-based Verbatim S08V1901-D1
also known as Gigabit Ethernet Hard Drive and perhaps other
funny names.
Link: https://github.com/openwrt/openwrt/pull/21989
Signed-off-by: Linus Walleij <linusw@kernel.org>
SerDes attached ports that are connected during switch
boot might not be able to transmit any data after SerDes
setup. Especially ports that passed traffic before (e.g.
for tftp initramfs boot) seem to be affected. Ports that
are connected later do not show this issue.
It turns out that the old SerDes setup never really worked
on RTL8382 and the pcs refactoring (with dynamic SerDes
start and stop) totally changed the order of network bringup
in contrast to Realtek SDK.
Fix this by restaring the switch queue whenever a SerDes
goes up for the first time.
Fixes: e956adf ("realtek: rtl838x: setup SDS in PCS driver")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21956
Signed-off-by: Robert Marko <robimarko@gmail.com>
The write protection register (0x1b000058) is opened up in prom init
but closed later in rtl838x_pie_init(). From that moment no more
special register writes are possible.
Only unlock the write protection register once during prom init.
Remove all other references. The error has been active since ages
but was not visible until pcs refactoring. For reference blame the
refactoring commit.
Fixes: e956adf ("realtek: rtl838x: setup SDS entirely in PCS driver")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21956
Signed-off-by: Robert Marko <robimarko@gmail.com>
Setup of register PLL_CML_CTRL has two issues.
- It clears out bits 4-31 due to a wrong mask
- Setup of bits 0-3 is not generic but depends on the mode of
serdes 0/1
Fix that by relocating the code and adapting the mask. The error
exists for longer but it has survived the pcs refactoring. Thus
blame the corresponding refactoring commit.
Fixes: b670d48 ("realtek: pcs: rtl838x: refactor imported code")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21956
Signed-off-by: Robert Marko <robimarko@gmail.com>
Drop leftovers from refactoring. Additionally convert all references
to the old dynamically calculated rings/ringsizes to the new ones.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21856
Signed-off-by: Robert Marko <robimarko@gmail.com>
Make use of the new structures and redesign the receive path.
Especially
- reduce lock usage
- drop KSEG() macros
- use DMA mapping instead of uncached access
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21856
Signed-off-by: Robert Marko <robimarko@gmail.com>
Define the needed structures for the redesign of the ethernet
receive path. They are closely aligned with the already refactored
transmit path.
The only exception is the additional data buffer where the
hardware can place the incoming data. This is allocated non-
coherent and data will be manually synchronized. The old design
used coherent (aka uncached) memory access.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21856
Signed-off-by: Robert Marko <robimarko@gmail.com>
Realtek switches have either 8 or 32 receive queues on the CPU port.
This is an overkill. Not only the CPUs have low performance but also
the queues need memory (currently ~4MB) and lots of them are rarely
used.
To mitigate that situation add a new setup routine that enforces CPU
packet receiving to a fixed number of queues. From observations one
can see that most of the packets (especially TCP) are received on a
single queue. To align with the transmit path, start with a limit of
2 receive queues.
To make it clear: This commit does not change the receive path or its
structures. It simply limits the number of queues that are filled by
the hardware.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21856
Signed-off-by: Robert Marko <robimarko@gmail.com>
The ring counters on RTL83xx allow a space of up to 15 entries.
But rings can be filled faster than data is received and might be
much larger defined (128 at the moment). Also NAPI processing
allows much more than 15 packets to be processed in one chunk.
Disable the counters and let the hardware automatically detect
the available buffers by the ownership flag. With this disable
a pseudo workaround that tried to mitigate the buffer filling
on RTL838x due to wrong setup.
Remark. This commit fixes several inconsistencies in the setup
code. RTL838x runs the setup twice with different values. RTL839x
does not run the setup at all.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21856
Signed-off-by: Robert Marko <robimarko@gmail.com>
Refresh the patches to make them apply cleanly again.
Fixes: 105eb9ca95 ("kernel: add cake-mq support")
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
There is now an implementation of .set_autoneg and .restart_autoneg for
all variants. Remove the helper function which checks for it, and just
call the operation directly.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/21934
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
RTL83xx uses the BMCR and ADVERTISE registers like RTL93xx to configure
in-band auto-negotiation. Split out the common parts as a new generic
implementation and use it for RTL83xx. RTL93xx retains its own variant
of set_autoneg to support XSGMII, but calls into the generic version for
all other modes.
Tested 1000Base-X auto-negotiation on HPE 1920-8G (RTL8380). Also tested
HPE 1920-24G (RTL8382) and HPE-1920-48G (RTL8393) to make sure this does
not affect PHY ports.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/21934
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add support for the TP-Link EAP683-LR, an AX6000 Ceiling Mount WiFi 6
AP.
Hardware:
* SoC: MediaTek MT7896AV
* RAM: 1GiB DDR4 (Samsung K4A8G165WC-BCTD)
* Flash: 128MiB SPI-NAND (ESMT F50L1G41LB)
* Ethernet: 1x 10/100/1000/2500 Mbps PoE-PD (MaxLinear GPY211C)
* WiFi: MT7976AN/MT7976GN 2.4/5GHz 4T4R
* LEDS: 3x blue connected to a single GPIO line
* Buttons: 1x reset
* BLE/Thread/Zigbee: CC2652
Stock firmware uses a random MAC address for ethernet, label MAC for
2.4 and label MAC + for 5GHz.
Installation via bootloader:
* Solder JST??? connector on J255, alternatively solder wires on the
TP13-TP15 pads. Pinout: TP13: TX, TP14: RX, TP15: GND, TP16: VCC.
The pins for J255 are in the same order.
* Interrupt boot process by repeatedly pressing Ctrl+b during boot
* In the boot menu, select U-Boot console
* Ensure the U-Boot environment variable "tp_boot_idx" is not set:
# setenv tp_boot_idx
# saveenv
* Boot the OpenWrt initramfs:
# tftpboot openwrt-mediatek-filogic-tplink_eap683-lr-initramfs-kernel.bin
# bootm
* copy openwrt-mediatek-filogic-tplink_eap683-lr-squashfs-sysupgrade.bin
to /tmp and install it using sysupgrade
Flashing via OEM firmware is currently not supported. The
tplink-safeloader utility does not recognize the OEM firmware:
DEBUG: can not find fwuphdr
Firmware image partitions:
base size name
Segmentation fault (core dumped)
To revert to the OEM firmware, you can set the U-Boot environment
variable "tp_boot_idx" to 1 via bootloader, or using fw_setenv via
OpenWrt. This should result in booting from the ubi1 partition, which
OpenWrt should not touch. Then use the web interface to upgrade
firmware: System > Firmware Update.
The OEM firmware uses 0x800000 for the runtime_backup partition size.
This causes the following warning:
mtd: partition "runtime_backup" extends beyond the end of device "nmbm_spim_nand" -- size truncated to 0x600000
This is due to the NMBM reserved blocks. Use 0x600000 in our DTS.
Thanks to init Lab's user890104, who soldered jumper wires on the TTL
pads for me so I could have serial console. My soldering skills just
aren't good enough to pull that off without risk damaging things.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Add the required patches in order to backport cake-mq from Linux 7.0.
Many thanks to Toke Høiland-Jørgensen for providing the git trees with backports
for both 6.12 and 6.18.
Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21964
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Bootlog has the following line:
mt7915e 0000:01:00.0: missing precal data, size=403472
It is because precal was not included in the previous NVMEM conversion.
Fix this by adding it to the dts.
Fixes: dbc2923cbe ("mediatek: filogic: convert Acer Predator W6 to use NVMEM framework")
Signed-off-by: Zhi-Jun You <hujy652@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/21894
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Bootlog has the following line:
mt7915e 0000:01:00.0: missing precal data, size=403472
It is because precal was not included in the previous NVMEM conversion.
Fix this by adding it to the common dts.
Fixes: dbc2923cbe ("mediatek: filogic: convert Acer Predator W6 to use NVMEM framework")
Signed-off-by: Zhi-Jun You <hujy652@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/21894
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Bootlog has the following line:
mt798x-wmac 18000000.wifi: missing precal data, size=403472
It is because precal was not included in the previous NVMEM conversion.
Fix this by adding it to the common dtsi.
Fixes: dbc2923cbe ("mediatek: filogic: convert Acer Predator W6 to use NVMEM framework")
Signed-off-by: Zhi-Jun You <hujy652@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/21894
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Convert the malta target from the legacy Image/BuildKernel and
Image/Build pattern to the modern Device macro system. This is the
last target still using the legacy pattern.
The Device macro system automatically generates per-image JSON
metadata files which get aggregated into profiles.json, enabling
firmware selector and other tooling support for all malta subtargets
(be, le, be64, le64).
The kernel ELF is produced via KERNEL_NAME := vmlinux.elf (matching
octeon), uImage artifacts are built using the standard Build/lzma,
Build/gzip and Build/uImage commands with the existing load address
0x80100000, and rootfs images use append-rootfs with optional gzip
compression.
The device is named 'generic' following the convention used by other
virtual/emulated targets (x86, armsr, octeon).
Signed-off-by: Paul Spooren <mail@aparcar.org>
These devices share the same "compatible" in device tree causing some
incompatibilities (sysupgrades, ASU profile identification), assign a
unique "compatible" and "model" to each variant.
Context:
Commit [1] added each variant's dts compatible to the SUPPORTED_DEVICES
field of the other variant to make easy sysupgrades between these
physically indistinguishable devices variants possible.
But there were found three issues which does not allow this:
- the sysupgrade's stricter check still used in some sysupgrade
paths(this check is being replaced(and redundant) with the newer fwtool's
SUPPORTED_DEVICES check using the info in images METADATA), this check
will fail when sysupgrading from a different board_name(compatible dts)
that the image was created for (image profile name).[2]
- ASU needs unique "dts compatible" to identify the devices profile.
- and an ASU's profile identification limitation when several devices from
a common target share SUPPORTED_DEVICES entries.[3]
There is a proposal for these issues but not yet implemented [4][3].
Until these issues are fixed we won't allow "easy" sysupgrades between
these two device variants.
Commit [5] avoided the ASU profile identification limitation but
missed the required two unique dts compatibles in order to make the two
variants fully work, although not allowing easy sysupgrade between them.
[1]: 8d30e07180
[2]: sysupgrade stricter check https://github.com/openwrt/openwrt/issues/20566#issuecomment-3583555482
[3]: ASU proposal https://github.com/openwrt/asu/pull/1533
[4]: allow easy sysupgrade proposal https://github.com/openwrt/openwrt/pull/20947
[5]: b71f4665cd
Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500")
Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision")
Fixes: https://github.com/openwrt/openwrt/issues/20566
Fixes: https://github.com/openwrt/asu/issues/1525
Signed-off-by: Mario Andrés Pérez <mapb_@outlook.com>
Link: https://github.com/openwrt/openwrt/pull/21842
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This reverts commit 66a7e04e9e.
Doing so makes the u-boot unable to find the node for this pcie
controller and disable it on mx60, resulting boot failure, as reported
in https://github.com/openwrt/openwrt/issues/21649 .
If we keep on treating mx60 and mx60w the same target, we might have
to endure the warning which 66a7e04 wants to eliminate.
Signed-off-by: Edward Chow <equu@openmail.cc>
Link: https://github.com/openwrt/openwrt/pull/21941
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Only configure the eth0 MAC address when it is not already done in the
device tree. To do this, create a new variable "eth0_mac".
Also avoid setting "label_mac" for devices already having it defined in
the device tree.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/21644
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Explicitly specify all devices where the MAC address is configured based
on the U-Boot environment.
This change makes it clearer which devices use this method. Also makes
things simpler for any future devices which handle MAC address
configuration entirely via device tree.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/21644
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Currently, the 02_network script always configures MAC addresses for
each individual LAN port unless "lan_mac_start" is set to "skip". This
behaviour can be unexpected, and is also somewhat broken, as it even
continues to do so when "lan_mac_start" is empty.
Change it to only do the configuration if "lan_mac_start" is non-empty,
and also remove the fallback to "lan_mac", making this more obvious and
less error-prone.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/21644
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The MAC address assignment for XikeStor SKS8300-8T and SKS8300-12E2T2X
is semantically identical to the first case, so let's combine them.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/21644
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
There is a missing tab in one of the cases of MAC address configuration.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Link: https://github.com/openwrt/openwrt/pull/21644
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
patch netlink headers for netifd PSE support
& fix PSE backports for PSE Prio
The 626-* patches are backporting net PSE-PD from
linux 6.18 to 6.12. The 627-02 is a nearly verbatim
copy of the upstream commit. The 6.12-01 patches the
auto generated ethtool_netlink_generated header.
The 6.12 build tools do not have the build system
feature for generating the correct netlink
headers related to the backports.
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/21926
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Upstream solution came with 6.4. Seems quilt refreshed it to the extent
that it basically gets applied twice.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21954
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Use the added support for generating per device targz rootfs so that images
generated for Methode devices when CONFIG_TARGET_MULTI_PROFILE and
CONFIG_TARGET_PER_DEVICE_ROOTFS are set, we actually get the targz rootfs
that respects DEVICE_PACKAGES.
Currently, buildbot generated images have no networking, LM75 nor I2C
working, as the generated images do not include required kmods that are
listed in DEVICE_PACKAGES.
While at it, there is no need for tar to run in verbose mode.
Fixes: 7dff6a8c89 ("mvebu: uDPU: add sysupgrade support")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Mikrotik RBM33G has got a USB-A port and mPCIe slots with USB 3.0 and USB
2.0 interfaces in use. The MediaTek MT7621 SoC has got an xHCI to provide
these interfaces. Therefore, enable kmod-usb3 to support them.
Fixes: 5684d08741 ("ramips: Add support for Mikrotik RouterBOARD RBM33g")
Signed-off-by: Chester A. Unal <chester.a.unal@arinc9.com>
The bus reset functions currently configure a lot of things. Looking
closely they have a topology setup and a polling setup part. Split the
big chunk in smaller better readable functions.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21906
Signed-off-by: Robert Marko <robimarko@gmail.com>
The downstream Realtek phy module is currently known as rtl83xx-phy.c
and its kernel config REALTEK_SOC_PHY. It has been simplified, cleaned
and now aligns to Realtek main module (upstream Realtek phy). It is no
longer tied to the Realtek switch SoC but serves as generic module for
1Gbit multiport phys. Adapt it as follows:
- place it into the realtek folder aside its upstream sibling
- rename it to realtek_multiport.c
- remove SoC dependency in Kconfig and Makefile
- change kernel configs for the targets accordingly
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21929
Signed-off-by: Robert Marko <robimarko@gmail.com>
Drop some lines that are not needed any longer.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21929
Signed-off-by: Robert Marko <robimarko@gmail.com>
If nvmem is used for ethernet mac address, we need to defer loading to
get the proper mac.
Move to probe as ndo_init is the wrong place to handle EPROBE_DEFER.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21920
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Sophos SG/XG-125 revision 3 like the already supported SG/XG-135
revision 3 has odd numbering of eth ports where the WAN port (as marked
on the case) is: `eth6` and `eth0`, `eth1`, `eth2`, `eth3`, `eth5`, `eth7`,
`eth8` are LAN ports.
Port `eth4` confirmed to be the SFP port.
Signed-off-by: Raylynn Knight <rayknight@me.com>
Link: https://github.com/openwrt/openwrt/pull/21914
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
meraki_loadaddr=1000000 may not enough to boot openwrt 25.12+ on mx60,
so directly sysupgrade without changing meraki_loadaddr would result
broken, but the u-boot-env partition used to be marked read-only, so
compat_version had better be incremented to show a notification to
direct users to the wiki to prepare the sysupgrade manually.
Signed-off-by: Edward Chow <equu@openmail.cc>
Link: https://github.com/openwrt/openwrt/pull/21912
Signed-off-by: Robert Marko <robimarko@gmail.com>
The main point of it currently is to extract mac addresses. That is not
being done as MAC addresses are elsewhere.
Disable it until it becomes more feature packed and there's an actual
use for it.
All devices already have config definitions. NVMEM prevents redundant
support as well as write support.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16618
Signed-off-by: Robert Marko <robimarko@gmail.com>
Needed to avoid probe errors.
There are two partitions from 0-20000 and 80000-100000.
This is redundant-count and not regular u-boot,env
Add status = "disabled" as the u-boot env driver can't handle redundant
environments properly. As a result, fw_printenv ends up not working
right.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16618
Signed-off-by: Robert Marko <robimarko@gmail.com>
Per the comments, this is not uboot,env but the redundant forms.
Placed under fixed-partition nodes in order to add status = "disabled".
The roots are needed for u-boot envtools to use.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16618
Signed-off-by: Robert Marko <robimarko@gmail.com>
With nvmem-layout, these probe errors go away.
Add status = "disabled" as the u-boot env driver can't handle redundant
environments properly. As a result, fw_printenv ends up not working
right.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16618
Signed-off-by: Robert Marko <robimarko@gmail.com>
With nvmem-layout, these probe errors go away.
Add status = "disabled" as the u-boot env driver can't handle redundant
environments properly. As a result, fw_printenv ends up not working
right.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/16618
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL930x and RTL931x basically share the same logic for mac_config().
No need to duplicate that logic in two functions and to call one
from the other.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21895
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
There is still a stray call in setup_serdes to read the current CMU
band. The only effect is that the current band is printed to the log, the
value itself isn't used for anything further. Drop this since it's not
needed.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21858
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The function 'rtpcs_931x_sds_init_leq_dfe' was taken over mostly as-is
from the SDK. After looking at what it actually does (by seeing which
register are written and how they are used elsewhere), it becomes clear
that 'init' isn't the correct term to describe what it does. It sets the
LEQ and DFE parameters to baseline values (mostly 0) and turns off auto
mode, switching to manual LEQ/DFE and forcing those baseline values.
This is rather a reset to a known state instead of an initialization.
Name the function accordingly.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21858
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add some comments to several register writes explaining what these
fields are. The information was extracted from the SDK. This allows to
understand much better what's going on there.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/21858
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
