add three missing LEDs
- PoE-Max
- Link/Act
- PoE
add two missing buttons
- mode
- reset
The last was dropped in
commit 61a3d0075b ("realtek: update GPIO bindings in the dts files in dts-5.10")
Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me>
General hardware info:
----------------------
D-Link DGS-1210-28MP rev. F1 is a switch with 24 ethernet ports and 4
combo ports, all ports Gbit capable. It is based on a RTL8382 SoC @ 500MHz,
DRAM 128MB and 32MB flash. 24 ethernet ports are 802.3af/at PoE capable
with a total PoE power budget of 370W.
Power over Ethernet:
--------------------
The PSE hardware consists of three BCM59121 PSE chips, serving 8 ports
each. They are controlled by a Nuvoton MCU.
In order to enable PoE, the realtek-poe package is required. It is
installed by default, but currently it requires the manual editing of
/etc/config/poe. Keep in mind that the port number assignment does not
match on this switch, alway 8 ports are in reversed order: 8-1, 16-9 and
24-17.
LEDs and Buttons:
-----------------
On stock firmware, the mode button is supposed to switch the LED indicators
of all port LEDs between Link Activity and PoE status. The currently
selected mode is visualized using the respective LEDs. PoE Max indicates
that the maximum PoE budget has been reached.
Since there is currently no support for this behavior, these LEDs and
the mode button can be used independently.
Serial connection:
------------------
The UART for the SoC (115200 8N1) is available via unpopulated standard
0.1" pin header marked J6. Pin1 is marked with arrow and square.
Pin 1: Vcc 3.3V
Pin 2: Tx
Pin 3: Rx
Pin 4: Gnd
OEM installation from Web Interface:
------------------------------------
1. Make sure you are booting using OEM in image 2 slot. If not, switch to
image2 using the menus
System > Firmware Information > Boot from image2
Tools > reboot
2. Upload image in vendor firmware via Tools > Backup / Upgrade
Firmware > image1
3. Toogle startup image via System > Firmware Information > Boot from
image1
4. Tools > reboot
Other installation methods not tested, but since the device shares the
board with the DGS-1210-28, the following should work:
Boot initramfs image from U-Boot:
---------------------------------
1. Press Escape key during `Hit Esc key to stop autoboot` prompt
2. Press CTRL+C keys to get into real U-Boot prompt
3. Init network with `rtk network on` command
4. Load image with `tftpboot 0x8f000000
openwrt-rtl838x-generic-d-link_dgs-1210-28mp-f-initramfs-kernel.bin`
command
5. Boot the image with `bootm` command
Signed-off-by: Andreas Böhler <dev@aboehler.at>
should be add/delete or abbreviated add/del
Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
The code in dsa.c:rtl83xx_port_enable() was trying to set
vlan_port_tag_sts_ctrl while dealing with differences between SoCs.
However, not only that register has a different address, the register
structure and even the 2-bit value semantic changes for each SoC.
The vlan_port_tag_sts_ctrl field was dropped and converted into a
vlan_port_keep_incoming_tag_set() function that abstracts the different
between SoCs. The macro referencing that register migrated to the SoC
specific c file as it will be privately used by each file.
All magic numbers were converted into macros using BITMASK and
FIELD_PREP.
The vlan_port_tag_sts_ctrl debugfs was dropped for now as it is already
broken for rtl93xx. The best place for SoC specific code might be in each
respective c file and not in if/else clauses.
The final result is:
rtl838x: set ITAG_STS=TAGGED, same as before
rtl839x: set ITAG_STS=TAGGED instead of IGR_P_ITAG_KEEP=0x1, fixing
forwarding of tagged packets
rtl930x: set EGR_ITAG_STS=TAGGED instead of IGR_P_ITAG=0x1, possibly
fixing forwarding of tagged packets
rtl931x: set EGR_ITAG_STS=TAGGED instead of OTPID_KEEP=0x1, possibly
fixing forwarding of tagged packets
Without (EGR_)ITAG_STS=TAGGED, at least for rtl839x, forwarded packets
will drop the vlan tag while packets from the CPU will still have the
correct tag.
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
The rtl930x speed status registers require 4 bits to indicate the speed
status. As such, we want to divide by 8. To make things consistent with
the rest of this code, use a bitshift however.
This bug probably won't affect many users yet, as there aren't many
rtl930x switches in the wild yet with more then 10 ports, and thus a
low-impact bugfix.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
[also fix port field extraction]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
After replacing the R4K event timer and clock source with the new
Realtek Otto timer, performance for RTL839x devices was severely
impacted, as reported by Hiroshi.
Research by Markus showed that after commit 4657a5301e ("realtek:
avoid busy waiting for RTL839x PHY read/write"), the ethernet driver
could only update a phy once per timer interval, which also heavily
impacted boot time. On e.g. a Zyxel GS1900-48, this added around a
minute to the time to fully initialise the switch.
By marking the otto clocksource as continuous, the kernel enables it to
be used for high resolution timers. This allows readx_poll_timeout() to
sleep for less than one system timer interval, reducing system dead
time.
Link: https://github.com/openwrt/openwrt/issues/11117
Reported-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Cc: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Tested-by: INAGAKI Hiroshi <musashino.open@gmail.com> # Panasonic Switch-M48eG PN28480K
Tested-by: Jan Hoffmann <jan@3e8.eu> # HPE 1920-8G, HPE 1920-48G
In rtl83xx_set_features we set bit 3 to enable, and bit 4 to disable
checksuming. Looking at rtl93xx_set_features we however see that for
both enable and disable the same bit is used (bit 4). This can't be
right, especially as bit 4 for rtl83xx seems to be Collision threshold
occupying 2 bits. Change this to make this more logical.
Fixes: 9e8d62e421 ("realtek: enable CRC offloading")
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
L2 learning on the CPU port is currently not consistently configured and
relies on the default configuration of the device. On RTL83xx, it is
disabled for packets transmitted with a TX header, as hardware learning
corrupts the forwarding table otherwise. As a result, unneeded flooding
of traffic for the CPU port can already happen on some devices now. It
is also likely that similar issues exist on RTL93xx, which doesn't have
a field to disable learning in the TX header.
To address this, disable hardware learning for the CPU port globally on
all devices. Instead, enable assisted learning to let DSA write FDB
entries to the switch.
For now, this does not sync local/bridge entries to the switch. However,
support for that was added in Linux 5.14, so the next switch to a newer
kernel version is going to fix this.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Initialize the data structure using memset to avoid the possibility of
writing garbage values to the hardware.
Always set a valid entry type, which should fix writing unicast entries
on RTL930x.
For unicast entries, set the is_static flag to prevent the switch from
aging them out.
Also set the rvid field for unicast entries. This is not strictly
necessary, as the switch fills it in automatically from a non-zero vid.
However, this makes the code consistent with multicast entry setup.
While at it, reorder the statements and fix some style issues (double
space, comma instead of semicolon at end of statement). Also remove the
unneeded priv parameter and debug print for the multicast entry setup
function.
Fixes: cde31976e3 ("realtek: Add support for Layer 2 Multicast")
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
The switches support different actions for incoming ethernet multicast
frames with Reserved Multicast Addresses (01-80-C2-00-00-{01-2F}). The
current code will set the 2-bit action field to FLOOD (0x3) for most
classes, but the highest bit is always unset for the relevant control
registers. This means the DROP (0x1) action being used for these
classes; whatever class the MSB happens to be in.
For RTL838x, this results in {20,23-2F} frames being dropped, instead of
flooding all ports. On other switch generations, {0F,1F,2F} frames are
dropped. This is inconsistent, and appears to be a mistake. Remove this
inconsistency by flooding all multicast frames with RMA addresses.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The multicast setup function rtl838x_eth_set_multicast_list() checks if
the current SoC is a RTL839x family device. However, the function is
only included in the RTL838x ops table, so this path should never be
taken, making this dead code. rtl839x_eth_set_multicast_list() is
already present in the RTL839x ops table, so it should be safe to remove
this branch.
While touching the code, also re-sort the functions to match sorting
elsewhere, with rtl838x coming before rtl839x.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Currently several messages at KERN_INFO level are printed for every FDB
del/dump operation. This can cause a significant slowdown for example
while using "bridge fdb", and may even trigger a watchdog.
Remove most of these log messages, as the new L2 table debugfs node
should be a good replacement. Change the remaining messages to
KERN_DEBUG level.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Switch to a polling implementation similar to the one for RTL838x, to
allow other kernel tasks to run while waiting.
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
The new timer is not yet ready for all targets. Avoid interactive
questions during build
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[rename symbol to CONFIG_REALTEK_OTTO_TIMER]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Use the new timer driver for the RTL839X devices and remove the
no longer needed modules.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[correct timer compatible order, update selected symbols]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Use the new timer driver for the RTL838X devices. Remove the no
longer needed modules.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[correct timer compatible order, update selected symbols]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Provide some helpful information about the devicetree configuration of
our new driver
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[correct compatible order in examples]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Now that we provide a clock driver for the Reltek SOCs the CPU frequency might
change on demand. This has direct visible effects during operation
- the CEVT 4K timer is no longer a stable clocksource
- after CPU frequencies changes time calculation works wrong
- sched_clock falls back to kernel default interval (100 Hz)
- timestamps in dmesg have only 2 digits left
[ 0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps ...
[ 0.060000] pid_max: default: 32768 minimum: 301
[ 0.070000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.070000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.080000] dyndbg: Ignore empty _ddebug table in a CONFIG_DYNAMIC_DEBUG_CORE build
[ 0.090000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, ...
Looking around where we can start the CEVT timer for RTL930X is a good basis.
Initially it was developed as a clocksource driver for the broken timer in that
specific SOC series. Afterwards it was shifted around to the CEVT location,
got SMP enablement and lost its clocksource feature. So we at least have
something to copy from. As the timers on these devices are well understood
the implementation follows this way:
- leave the RTL930X implementation as is
- provide a new driver for RTL83XX devices only
- swap RTL930X driver at a later time
Like the clock driver this patch contains a self contained module that is SOC
independet and already provides full support for the RTL838X, RTL839X and
RTL930X devices. Some of the new (or reestablished) features are:
- simplified initialization routines
- SMP setup with CPU hotplug framework
- derived from LXB clock speed
- supplied clocksource
- dedicated register functions for better readability
- documentation about some caveats
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
[remove unused header includes, remove old CONFIG_MIPS dependency, add
REALTEK_ prefix to driver symbol]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
In *_enable_learning() only address learning should be configured, so
remove enabling forwarding. Forwarding is configured by the respective
*_enable_flood() functions.
Clean up both functions for RTL838x and RTL839x, and fix the comment on
the number of entries.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
[squash RTL838x, RTL839x changes]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Those messages should be printed when entry was found (idx >= 0). Move
them to the right place to not print invalid entry indices.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
[amden commit message]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The initial state of sds_mode in rtl9300_force_sds_mode() is null and it
will be configured in switch-case. So print message after it.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
[amend commit message]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Use the generic function of MIPS in Linux Kernel instead of open coding
our own initialisation.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
[amend commit message]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The availabibity of probing CPC depends on CONFIG_MIPS_CPC symbol and it
will be checked in arch/mips/include/asm/mips-cpc.h. RTL9310 selects
this symbol, so the family check is redudant.
Furthermore, mips_cm_probe() is already called from setup_arch() in
mips/kernel/setup.c before prom_init(), and as such is not required.
Also move mips_cpc_probe() to run just before registering SMP ops.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
[squash SMP change commits, reword commit message]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
---
This patch only really has an impact on the rtl931x subtarget, which has
no devices. Noboby is currently set up to test these patches either, but
the end result is closer to MIPS_GENERIC, so I do not expect it to cause
issues.
RTL8231 and ethernet phys are not on the same bus, so separate the lock
to each own to cut off the unnecessary dependency.
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
The workaround for an already-enabled R4K timer used a non-existent
macro CAUSE_DC. Fix compiling by using the actual macro CAUSEF_DC.
Fixes: b7aab19585 ("realtek: SMP handling of R4K timer interrupts")
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Until now there has been no good explanation why we mess with the R4K
timer on SMP. After extensive testing and looking at the SDK code it
becomes clear what it is all about.
When we disable the CEVT_R4K module (we will do with the new timer
driver) the R4K timer hardware still fires interrupts on the secondary
CPU. To get around this we have two options:
- Disable IRQ 7
- Stop the counter completely
This patch selects option two because this is the root of evil.. To be
on the safe side we will do it only in case the CEVT_R4K module is
disabled.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The scope of the SMP startup structure is wrong. It is created on the
stack and not as a global variable. This can lead to startup failures.
Fixes: 3f41360eb7 ("realtek: use upstream recommendation for CPU start")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de
OpenWRT's developer guide prefers having actual patches so they an be
sent upstream more easily.
However, in this case, Adding proper fields also allows for `git am` to
properly function. Some of these patches are quite old, and lack much
traceable history.
This commit tries to rectify that, by digging in the history to find
where and how it was first added.
It is by no means perfect and also shows some patches that should have
been long gone.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
When the realtek clock driver was introduced, CONFIG_COMMON_CLK_REALTEK
was not correctly disabled for other subtarget. Add the missing config
flag to fix compilation error on buildbot.
Fixes: 4850bd887c ("realtek: add RTL83XX clock driver")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Don't overwrite AS_DPM and L2LEARNING flags when dest_port is >= 32.
Fixes: 1773264a0c ("realtek: correct egress frame port verification")
Signed-off-by: Jan Hoffmann <jan@3e8.eu>
Currently we fix interrupts/timers for the secondary CPU by patching
vsmp_init_secondary(). Get a little bit more generic and use the
upstream recommended way instead. Additionally avoid a check around
register_cps_smp_ops() because it does that itself.
See https://lkml.org/lkml/2022/9/12/522
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The interrupt controller depends on two control registers. GIMR enables
or disables interrupts and IRRx routes these to MIPS CPU interrupts 2-7.
Wiki currently states "A value of '0' (in IRRx) disconnects this input from
the output line, independent of the line's setting in GIMR."
Contrary to normal intuition this statement DOES NOT mean, that interrupts
can be disabled by IRRx alone. The sad truth was discovered by enabling
SMP for an Zyxel XGS1010 on the 930x target. It shows that driver and
interrupts behave as follows:
- Timer 0 interrupt 7 has active routing to CPU0 and no routing to CPU1
- Timer 1 interrupt 8 has no routing to CPU0 and active routing to CPU1
- Unmasking (enabling) interrupts writes 1 bits to all GIMR registers
- Masking (disabling) interrupts writes 0 bits to both GIMR registers
During operation we can encounter a situation like
- GIMR bit for a interrupt/CPU combination is set to enabed (=1)
- IRRx routing bits for a interrupt/CPU combination are set to disabed (=0)
This setting already allows the hardware to fire interrupts to the target
CPU/VPE if the other CPU/VPE is currently busy. Especially for CPU bound
timer interrupts this is lethal. If timer interrupt 7 arrives at CPU1 and
vice versa for interrupt 8 the restart trigger gets lost. The timer dies
and a msleep() operation in the kernel will halt endlessly.
Fix this by tracking the IRRx active routing setting in a new bitfield with
0="routing active" and 1="no routing". Enable interrupts in GIMR only
for a interrupt & CPU if routing is active. Thus we have
- GIMR = 0 / IRRx = 0 -> everything disabled
- GIMR = 1 / IRRx > 0 -> active and normal routing
- GIMR = 0 / IRRx > 0 -> masked (disabled) with normal routing
- GIMR = 1 / IRRx = 0 -> no longer possible
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
The Build prefix is used for image build commands, while the Device
prefix should be used for base recipes for devices. Apply the same
naming convention here.
While touching the file, also fix the mixed indentation.
Suggested-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Signed-off-by: Sander Vanheule <sander@svanheule.net>
There seems to be no reason to have the Netgear switches as part of
the main Makefile. Move it to its subtarget-specific Makefile since
it is only applicable there.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
[update commit message]
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Currently supported HPE 1920 devices all have an RTL838x SoC, but there
are larger switches with RTL839x SoCs, although currently not supported.
Move the build recipe to common.mk so the larger devices can also make
use of the recipe, while moving it out of the main Makefile.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
The D-Link DGS-1210 device series currently has supported devices with
both RTL838x and RTL839x SoCs. An image build recipe has been defined in
both subtarget makefiles, but these are mostly identical, save for the
SOC variable.
Move the SOC variable from the DGS-1210 build recipes to the applicable
devices, and put the remaining duplicate code in a shared Makefile.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Hardware specification
----------------------
* RTL8393M SoC, 1 MIPS 34Kc core @ 700MHz
* 128MB DRAM
* 32MB NOR Flash
* 48 x 10/100/1000BASE-T ports
- 6 x External PHY with 8 ports (RTL8218D)
* 4 x Gigabit RJ45/SFP Combo ports
- External PHY with 4 SFP ports (RTL8214FC)
* Power LED
* Reset button on front panel
* UART (115200 8N1) via unpopulated standard 0.1" pin header marked J14
The gpio-restart node is not required but it does reset the switch.
TODO: The 4 combo ports attached to the RTL8214FC are not detect
properly. Linux kernel reports 49 and 50 as "External RTL8393 SERDES"
and 51 and 52 as "RTL8218B (external)". Those ports only work if
u-boot initialize it (for example, loading initramfs image using one
of those ports). A patch to PHY detection is needed for full support.
The firmware recovery using U-Boot is broken for all DGS-1210 tested
devices as pressing RESET does not trigger it (only if pressed from a
running stock image)
UART pinout
-----------
[o]ooo|J14
| ||`------ GND
| |`------- RX
| `-------- TX
`---------- Vcc (3V3)
Installation using OEM upgrade
------------------------------
1. Make sure you are running OEM firmware in image2 slot (logged as admin):
- > config firmware image_id 2 boot_up
- > reboot
2. Install squashfs-factory_image1.bin to image1 using (logged as admin):
- > download firmware_fromTFTP <tftpserver> factory_image1.bin
- > config firmware image_id 1 boot_up
- > reboot
Installation using serial interface
-----------------------------------
1. Press Escape key during `Hit Esc key to stop autoboot` prompt
2. Press CTRL+C keys to get into real U-Boot prompt
3. Init network with `rtk network on` command
4. Load image with `tftpboot 0x8f000000 openwrt-realtek-rtl839x-d-link_dgs-1210-52-initramfs-kernel.bin` command
5. Boot the image with `bootm` command
Once booted the initramfs, install the squashfs-sysupgrade.bin as a
normal OpenWrt system.
Dual-boot with stock firmware using writable u-boot-env
-------------------------------------------------------
From stock to OpenWrt / boot image 1 (CLI as admin):
- > config firmware image_id 1 boot_up
- > reboot
From OpenWrt to stock / boot image 2: (shell as root)
- # fw_setenv bootcmd 'run addargs ; bootm 0xb4e80000'
- # fw_setenv image '/dev/mtdblock7'
- # reboot
Debrick using serial interface
------------------------------
1. Press Escape key during `Hit Esc key to stop autoboot` prompt
2. In a Windows PC, run 'D-Link Network Assistant v2.0.2.4'. It should
detect the switch
3. Flash the firmware.
Back to stock firmware using dual-boot
--------------------------------------
If you have serial interface, you can change u-boot env vars
interrupting the boot process. If not but you are running OpenWrt, you
can dual-boot (as mentioned eariler) and skip to step 4:
1. Press Escape key during `Hit Esc key to stop autoboot` prompt
2. Press CTRL+C keys to get into real U-Boot prompt
3. Boot the image 2:
- set image /dev/mtdblock7; run addargs; bootm 0xb4e80000
4. Once booted, log as admin and change the boot image to 2
- > config firmware image_id 2 boot_up
- > reboot
5. After the boot, flash image1 with the vendor image
Back to stock firmware using DNA
--------------------------------
1. From an OpenWrt:
- # fw_setenv bootstop on
- # reboot
2. In a Windows PC, run 'D-Link Network Assistant v2.0.2.4'. It should
detect the switch
3. Flash the firmware.
It has been developed and tested on device with F3 revision.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
The D-Link DGS device tree was reorganized to better reflect the common
DT parts. The common include is named SOC specific (838X) and it seemed
like a good choice to add another common include in the future for the
RTL839X devices. From the current point of view this option is not really
needed.
1. The common part only includes data that matches RTL839X devices too.
2. The Panasonic DT structure avoids including the basic DTSI inside the
common DTSI.
Taking simplicity of the Panasonic include logic and in perparation to
provide DGS-1210-52 support it makes sense to harmonize this.
- rename common include to reflect its content
- move the link to the root DTSI directly to the device specific DTS
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Due to an oversight we accidentally inverted the timeout check. This
patch corrects this.
Fixes: 9cec4a0ea4 ("realtek: Use built-in functionality for timeout loop")
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
[ wrap poll_timeout line to 80 char ]
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
In commit 81e3017609 ("realtek: clean up rtl838x MDIO busy wait loop")
a hand-crafted loop was created, that nearly exactly replicate the
iopoll's `read_poll_timeout` functionality.
Use that instead.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
