Currently, the MT7530 DSA subdriver configures the MT7530 switch to provide
direct access to switch PHYs, meaning, the switch PHYs listen on the MDIO
bus the switch listens on. The PHY muxing feature makes use of this.
This is problematic as the PHY may be attached before the switch is
initialised, in which case, the PHY will fail to be attached.
Since commit 91374ba537bd ("net: dsa: mt7530: support OF-based registration
of switch MDIO bus") on mainline Linux, we can describe the switch PHYs on
the MDIO bus of the switch on the device tree.
When the PHY is described this way, the switch will be initialised first,
then the switch MDIO bus will be registered. Only after these steps, the
PHY will be attached.
Describe the switch PHYs on mt7621.dtsi and remove defining the switch PHY
on the SoC's mdio bus node. When the PHY muxing is in use, the interrupts
for the muxed PHY won't work, therefore delete the "interrupts" property on
the devices where the PHY muxing feature is in use.
Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
Initial conversion to new LED color/function format
and drop label format where possible. The same label
is composed at runtime.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Some MT7915 calibration data consists of two parts. The first part
"eeprom" size is 0xe00. The second part "precal" size is 0x19c10.
Though some devices may not have precal data, it's better to assume
that precal data exists as no users/developers confirm it. On the
other hand, some devices definitely do not contain precal data
because the EEPROM partition size is smaller than the precal NVMEM
cell size.
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
Some MT7915 devices need to load the second part of the eeprom to
work properly. The mt76 driver is not yet ready to read the pre-cal
data via the NVMEM cell. Therefore, partially revert commit to fix
the device probe issue on some devices.
P.S.
Except for D-Link and Ubnt devices, It is still uncertain whether
pre-cal data is required for other devices in the patch.
This partially reverts commit 9ac891f8c4.
Fixes: https://github.com/openwrt/openwrt/issues/13700
Signed-off-by: Shiji Yang <yangshiji66@qq.com>
It was brought to attention the Archer AX23 v1 fails to read jffs2 data
from time to time. While this is not reproducible on my unit, it is on
others.
Reducing the SPI frequency does the trick. While it worked with at lest
40 MHz, opt for the cautious side and choose a save frequency of 25 MHz.
Apply the same treatment to the Mercusys MR70X which uses a similar
design just in case.
Signed-off-by: David Bauer <mail@david-bauer.net>
Hardware
--------
CPU: MediaTek MT7621 DAT
RAM: 128MB DDR3 (integrated)
FLASH: 16MB SPI-NOR ()
WiFi: MediaTek MT7905 + MT7975 (2.4 / 5 DBDC) 802.11ax
SERIAL: 115200 8N1
LEDs - (3V3 - GND - RX - TX) - ETH ports
Installation
------------
Upload the factory image using the Web-UI.
Web-Recovery
------------
The router supports a HTTP recovery mode by holding the reset-button
when powering on. The interface is reachable at 192.168.0.1 and supports
installation using the factory image.
Signed-off-by: David Bauer <mail@david-bauer.net>
