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>
Currently, the CMU is configured after media specific settings have been
set. This seems to work however does not make that much sense. The
proper clock should be configured before the TX/RX channels are
configured. Thus, move the call to the CMU configuration above the media
handling.
While at it, handle the return code of the CMU config properly.
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 SerDes setup for RTL931x relies on chip specifics in some cases,
Determining both usually requires some register operations. But we can
avoid to do this every time again and again since the information is
static anyway. Thus, move this to initialization for RTL93xx, only read
once and store it in the global control structure. Though not used for
RTL930x, it has the same registers and information.
While at it, give referenced defines a proper prefix.
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>
From the Realtek SDK we know that the chip type tell us whether a chip
is a normal chip or an engineering sample/testchip [1]. Such engineering
samples likely never reach any consumer device, only some initial
development boards. So far we haven't encountered any device with that,
thus the code paths handling this are practically dead and can hardly be
checked of they work properly. To focus on support for the devices we
actually have, drop support for such engineering samples/testchips. This
may be readded later if there's sufficient need for this.
[1] 3261cf2e61/sources/rtk-dms1250/system/drv/swcore/chip_probe.c (L345)
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>
Drop a register write sequence from the USXGMII setup for RTL931x in
favor of using a function that is already present. From the name, the
function initializes LEQ DFE. Though it's not yet clear what it exactly
does, this is already better then having a sequence with no explanation
somewhere in the code.
Apparently, when this code was added, the function wasn't present
but it's content was just added here as single usage.
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>
Backport the PSE-PD (Power Sourcing Equipment - Powered Device)
framework updates from Linux 6.13 through 6.19. This brings modern
PoE (Power over Ethernet) controller support to OpenWrt, enabling
userspace control of PSE hardware via ethtool.
Key features:
- Enhanced ethtool integration for PSE status and configuration
- Power domain support with budget evaluation strategies
- PSE event reporting via netlink
- Port priority management for power budget allocation
- New Si3474 PSE controller driver
Backported commits:
v6.13 core framework and TPS23881 improvements:
- 6e56a6d47a7f net: pse-pd: Add power limit check
- 0b567519d115 net: pse-pd: tps23881: Simplify function returns
- 4c2bab507eb7 net: pse-pd: tps23881: Use helpers to calculate bit offset
- f3cb3c7bea0c net: pse-pd: tps23881: Add missing configuration register
- 3e9dbfec4998 net: pse-pd: Split ethtool_get_status
into multiple callbacks
- 4640a1f0d8f2 net: pse-pd: Remove is_enabled callback from drivers
- 7f076ce3f173 net: pse-pd: tps23881: Add power limit
and measurement features
- 10276f3e1c7e net: pse-pd: Fix missing PI of_node description
- 5385f1e1923c net: pse-pd: Clean ethtool header of PSE structures
v6.17 power domains and event support:
- fa2f0454174c net: pse-pd: Introduce attached_phydev to pse control
- fc0e6db30941 net: pse-pd: Add support for reporting events
- f5e7aecaa4ef net: pse-pd: tps23881: Add support for PSE events
- 50f8b341d268 net: pse-pd: Add support for PSE power domains
- 1176978ed851 net: ethtool: Add support for power domains index
- c394e757dedd net: pse-pd: Add helper to report hw enable status
- ffef61d6d273 net: pse-pd: Add support for budget evaluation strategies
- 359754013e6a net: pse-pd: pd692x0: Add PSE PI priority feature
- 24a4e3a05dd0 net: pse-pd: pd692x0: Add controller and manager power
- 56cfc97635e9 net: pse-pd: tps23881: Add static port priority feature
- d12b3dc10609 net: pse-pd: pd692x0: reduce stack usage
v6.18 Si3474 driver and fixes:
- 1c67f9c54cdc net: pse-pd: pd692x0: Fix power budget leak
- 7ef353879f71 net: pse-pd: pd692x0: Skip power budget when undefined
- a2317231df4b net: pse-pd: Add Si3474 PSE controller driver
v6.19 maintenance and TPS23881B support:
- 2c95a756e0cf net: pse-pd: tps23881: Fix current measurement scaling
- f197902cd21a net: pse-pd: pd692x0: Replace __free macro
- 6fa1f8b64a47 net: pse-pd: pd692x0: Separate configuration parsing
- 8f3d044b34fe net: pse-pd: pd692x0: Preserve PSE configuration
- 4d07797faaa1 net: pse-pd: tps23881: Add support for TPS23881B
Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Link: https://github.com/openwrt/openwrt/pull/21810
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Add board support for the Xikestor SKS8300-12E2T2X switch.
Hardware specifications:
========================
-Realtek RTL9302C SoC, 1x MIPS-34Kc, 800 MHz
-512 MB DDR3 RAM
-32 MB SPI-NOR Flash
-12x 2.5GBASE-T Ports (RTL8224)
-2x 10GBASE-T Ports (RTL8261)
-2x 10G SPF+ Ports
-Reset Button on the front panel
-Power & SYS LED's
-UART (115200 8N1) via RJ45
Flash instruction:
==================
-Prepare TFTP server & connect to serial port
-Connect your computer to one of the RJ45 ports
-Power on and interrupt autoboot with Shift + A.
-Use Shift + Q to drop from vendor CLI to U-Boot CLI.
-Change U-Boot Bootcommand (needed for network functionality):
> setenv bootcmd 'rtk network on; boota'
> saveenv
-Start network:
> rtk network on
-Set switch IP and TFTP server IP:
> setenv ipaddr [IP-ADDRESS]
> setenv serverip [IP-ADDRESS]
-Load initramfs image from TFTP server:
> tftpboot 0x82000000 [IMAGEFILE]
-Boot with the downloaded image:
> bootm 0x82000000
-Backup the stock firmware if needed
-Perform sysupgrade with the sysupgrade image (in Luci or Terminal via scp & sysupgrade)
Back to stock firmware:
=======================
-In the Terminal enter:
> fw_setenv bootcmd 'boota'
-Write firmware with:
> sysupgrade -F [IMAGEFILE]
Signed-off-by: Michael Wagenhofer <michael@wagenhofer.de>
Link: https://github.com/openwrt/openwrt/pull/21773
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Looking at the Realtek mdio busses there are curently the following
root@OpenWrt:~# mdio
1b000000.switchcore:mdio-controller-mii
fixed-0
realtek-aux-mdio
realtek-serdes-mdio
rtldsa_mdio-0
The main mdio bus for the phys is named after the dts node it belongs
to (1b000000.switchcore:mdio-controller-mii). As it is attached to the
controller node it is even more confusing.
Align the naming to the other busses and use "realtek-mdio".
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21702
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The phy driver still uses the ancient unknown firmware file format
for the internal RTL8218B of the RTL838x. Get rid of that and
convert the initialization to the bare minimum.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/21885
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
