mediatek: cudy: fixes typo for spi and mtd properties
Same as commit 3674689, correct 'buswidth' to 'bus-width'. Move the nmbm properties outside the partition definition. Change uppercase to lowercase, add missing read-only flag.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn> (commit: ab375a3)
New revisions of Xiaomi AX3000T with 1.0.84+ stock firmware contain new hardware. This commit add support for Airoha AN8855 gigabit switch driver with 6.6 kernel patches
Based on https://patchwork.kernel.org/project/netdevbpf/cover/20241209134459.27110-1-ansuelsmth@gmail.com/
Signed-off-by: Dim Fish <dimfish@gmail.com> Link: https://github.com/openwrt/openwrt/pull/16709 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: 0fd9d00)
kernel: vrx518_tc: fix RX desc phys to virt mapping
It looks like VRX518 returns phys addr of data buffer in the 'data_ptr' field of the RX descriptor and an actual data offset within the buffer in the 'byte_off' field. In order to map the phys address back to virtual we need the original phys address of the allocated buffer.
In the same driver applies offset to phys address before the mapping, what leads to WARN_ON triggering in plat_mem_virt() function with subsequent kernel panic:
WARNING: CPU: 0 PID: 0 at .../sw_plat.c:764 0xbf306cd0 [vrx518_tc@8af9f5d0+0x25000] ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = aff5701e [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM
Noticed in ATM mode, when chip always returns byte_off = 4.
In order to fix the issue, pass the phys address to plat_mem_virt() as is and apply byte_off later for proper DMA syncing and on mapped virtual address when copying RXed data into the skb.
Run tested with FRITZ!Box 7530 on both ADSL and VDSL (thanks Jan) links.
ATM TC layer have some issues which effectively prevent VRX518 from being used as ADSL modem. Specifically, there one crash during the ATM layer configuration and wrong PVC ID selection on packet receiving what breaks RX path. Fix both of the issues. Make subif iface registration optional to prevent the crash (see more details in the new patch) and update the hardcoded PVC ID to match the first allocated channel.
atm_qos struct should be the same both for user and kernel spaces. Via the __SO_ENCODE() macro it is used to define the SO_ATMQOS socket IOC.
During the VRX518 support introduction, the atm_trafprm sturct nested into the atm_qos stucture was update with newer fields that are referenced by the ATM TC layer of the VRX518 TC driver. These new fields are intended to communicate information for extra traffic classes supported by the driver. But we are still using vanilla kernel headers to build the toolchain. Due to the atm.h header incoherency br2684ctl from linux-atm tools is incapable to configure the ATM bridge netdev:
br2684ctl: Interface "dsl0" created sucessfully br2684ctl: Communicating over ATM 0.1.2, encapsulation: LLC br2684ctl: setsockopt SO_ATMQOS 22 <-- EINVAL errno br2684ctl: Fatal: failed to connect on socket; File descriptor in bad state
There are two options to fix this incoherency. (a) update the header file in the toolchain to build linux-atm against updated atm_trafprm and atm_qos structures, or (b) revert atm_trafprm changes.
Since there are no actual users of the extra ATM QoS traffic classes, just drop these extra traffic classes from vrx518_tc ATM TC layer and drop the kernel patch updating atm.h.
Besides fixing the compatibility with linux-atm tools, removing the kernel patch should simplify kernel updates removing unneeded burden of maintenance.
Run tested with FRITZ!Box 7530 with disabled extra traffic classes and then removed them entirely before the submission.
qualcommax: add missing WAN LED support to Spectrum SAX1V1K routers
Fixed an issue where both WAN LEDs light up before plugging in the ethernet cable and no blinking regardless of WAN network activity.
Updated the LED configuration to reflect proper status: Green indicates 2.5Gb connection speed. Yellow indicates other connection speed and traffic activity.
This resolves inconsistent WAN LED behavior on Spectrum SAX1V1K routers.
Signed-off-by: Ivan Deng <hongba@rocketmail.com> Link: https://github.com/openwrt/openwrt/pull/17623 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 8e78bc3)
Supported devices are listed in the metadata as the first part of the DTS compatible. This normally follows the format "vendor,device".
When updating the device name of the 180W 1920-8G PoE an underscore was used, instead of a comma, to join the vendor and device name. This will lead to warnings for users wanting to sysupgrade a device with an older compatible, as the device's info does not match the one the metadata.
Fixes: 987c96e88927 ("realtek: rename hpe,1920-8g-poe to match hardware") Signed-off-by: Sander Vanheule <sander@svanheule.net> (commit: 6a7fa68)
This adds support for running as a guest on Windows Hyper-V on arm64 Windows machines (like the Qualcomm Snapdragon X based machines). The drivers are the same as Hyper-V on x86-64.
Limitations: - The VM must be configured with a single vCPU only[1].
It appears Microsoft has made changes to Arm64 Hyper-V's timers and other infrastructure in Windows 11 24H2 which require kernel changes[2][3] to fix.
- You must turn off secure boot enforcement to boot OpenWrt, as OpenWrt/armsr does not have a signed bootloader.
the wifi leds of the wax206 were not reacting. This patch enables the green leds to show activity, as the blue ones are very bright. Also set the label-mac to the gmac0
kernel: Make kmod-usb-chipidea select kmod-phy-ath79-usb
The USB PHY on the ar9330 and similar SoCs needs the PHY driver. In OpenWrt 23.05 it was compiled into the kernel. The kernel 6.6 configuration does not compile it in any more, make the kmod-usb-chipidea driver select it to add it to the images.
Fixes: https://github.com/openwrt/openwrt/issues/17710 Fixes: 04bdf9b3323e ("ath79: disable ath79 USB phy drivers by default") Link: https://github.com/openwrt/openwrt/pull/17720 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> (commit: b467e5a)
As the bootloader is reconfiguring the RTL8231 on these devices anyway, no pin state can be maintained over warm reboots. This results in for example the PoE disable pin always being asserted by the bootloader.
Define the GPIO line linked to the RTL8231's reset so the MDIO subsystem will also reset the expander on boot and ensure the line in the correct state.
Some RTL8380M-based devices have been around for a long time and use an early A revision of the RTL8380M SoC. This revision has an issue with the auxiliary MDIO controller, causing it to malfunction. This may lead to device reboots when the controller is used.
Provide a bit-banged MDIO bus, which muxes the auxiliary MDIO pins to their GPIO function. Although this will result in lower performance, there should otherwise be no functional differences.
In order to be able to define the external GPIO controller on an emulated MDIO bus, move the controller definition outside of the main GS1900 include for RTL838x-based devices.
Additionally, a new DTSI is provided defining the RTL8231 on the emulated MDIO bus.
The mdio-gpio driver is required to support early revision of RTL8380M slicon (rev A) where the auxilairy MDIO controller does not function correctly. Add this driver to the rtl838x kernel so devices with old SoCs are also able to function correctly.
Zyxel GS1900-8 v2 devices have been produced more recently than v1 devices. As there are v1 boards with RTL8380M rev. C SoCs, it can likely safely be assumed that all v2 devices will also have a recent SoC revision, supporting the hardware auxiliary MDIO controller.
Make the GS1900-8 v1 use an emulated auxiliary MDIO bus, for backward compatibility with devices containing an RTL8380M rev. A.
Since the devicetrees are otherwise identical, GS1900-8 v1 devices with an RTL8380M rev. B or C will also be able to use the (more efficient) v2 image. This includes any currently functioning device with OpenWrt, so include the old compatible as a supported device for the GS1900-8 v2.
qualcommbe: ipq95xx: Add initial support for new target
Add initial support for new target with the initial patch for ethernet support using pending upstream patches for PCS UNIPHY, PPE and EDMA.
Only initramfs currently working as support for new SPI/NAND implementation, USB, CPUFreq and other devices is still unfinished and needs to be evaluated.
Link: https://github.com/openwrt/openwrt/pull/17725 Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> (commit: 93173ae)
generic: fix probe issues with RealTek RTL8221B PHYs
Import patch "net: phy: realtek: mark existing MMDs as present"
When using Clause-45 mode to access RealTek RTL8221B 2.5G PHYs some versions of the PHY fail to report the MMDs present on the PHY. Mark MMDs PMAPMD, PCS and AN which are always existing according to the datasheet as present to fix that.
Fixes: #16823, #17183, #17232 Signed-off-by: Daniel Golle <daniel@makrotopia.org> Tested-by: Aleksander Jan Bajkowski <olek2@wp.pl> Tested-by: Juan Pedro Paredes Caballero <juanpedro.paredes@gmail.com> (commit: 730db6b)
Update to include the latest upstream improvements and bugfixes, including pahole now always encoding reproducibly.
Drop the local patch: 100-reproducible-builds.patch
Release Notes: https://lore.kernel.org/bpf/Z4-TDt42dTKZvCo6@x1/ Signed-off-by: Tony Ambardar <itugrok@yahoo.com> Link: https://github.com/openwrt/openwrt/pull/17705 Signed-off-by: Robert Marko <robimarko@gmail.com> (commit: 22d1e6c)
322500403615 service: add default group @ to match all nodes 5f7860306200 ubus: rename unetd_ubus_notify to unetd_ubus_network_notify d13752814651 enroll: add PEX sub-protocol to support enrolling new nodes into a network
Signed-off-by: Felix Fietkau <nbd@nbd.name> (commit: c0f06cb)
Change devices with RTL8231 GPIO expander definition that can easily be translated to the new RTL8231 binding and carry over any gpio-hogs. This will let them use the new RTL8231 MFD driver, without any functional changes.
It's possible to add the driver for the Marvell MV88E6xxx DSA switches using a module package rather than to compile it into the kernel. For affected devices this saves a bit of space, typically the DSA core is 600 KB so this and some more is saved for devices with no DSA switch.
When adding the packages I went over both the upstream DTS files and the OpenWrt-specific DTS files and used grep 'marvell,mv88e6' to find the devices using these switches.
It's possible to add the driver for the Marvell MV88E6xxx DSA switches using a module package rather than to compile it into the kernel. For affected devices this saves a bit of space, the DSA core alone is around 600 KB on ARM.
I could only find one device actually using this switch (I also checked upstream DTS files) so I have added the package to that one device.
In the config CONFIG_NET_DSA_TAG_TRAILER and CONFIG_NET_DSA_OCELOT were also selected, which seems like mistakes. These taggers are only used by the MV88E6060 and driver which is a separate switch from MV88E6xxx and the Ocelot drivers such as CONFIG_NET_DSA_MSCC_FELIX or CONFIG_NET_DSA_MSCC_SEVILLE and no qoric platform seems to be using them, nor are they selected in the config.
![[Jenkins]](/jenkins/static/65653afc/images/svgs/logo.svg){kind=logo}
