rtmdio_probe() is a do-it-all setup function. It creates one
control structure and one bus. In the future multiple busses
will be created. As a preparation carve out the bus specific
part into an individual probing function.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
Until now the central control structure is allocated via a call to
devm_mdiobus_alloc_size(). This will not be possible any longer when
multiple busses will be implemented in a future commit.
Relax that as follows:
- Define a new private "channel" structure for a mdio bus
- Allocate the central control structure with a dedicated alloc()
- Allocate only the channel structure during bus setup
- Link the channel to the central structure via chan->ctrl
Reorganize the probing function so that it becomes clearer that
the control structure is setup first and afterwards the bus is
registered.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add a new helper macro rtmdio_ctrl_from_bus that encapuslates
the current ctrl=bus->priv lookup. This is a preparation for
the future multi-channel driver architecture. With an upcoming
commit the structures will be changed as follows:
- ctrl: contains the generic data structurs
- chan: contains the channel specific structure
This will involve changing the pointers between them
old lookup chain: ctrl = bus->ctrl
new lookup chain: ctrl = bus->chan->ctrl
The helper macro allows to easily switch the lookup in one
central location. While we are here fix a whitespace issue.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
The topology setup is bus independent and can be derived completely
from the control structure. Adapt the call parameters accordingly.
The call location is quite confusing at the moment. Being no longer
dependent from the bus call it where it makes most sense. This is
directly after the mapping setup in rtmdio_map_ports(). Doing other
bus dependent setup between these two functions is not needed
any longer.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
The port specific attributes of the central control structure
have been moved over to a separate port structure. Do the same
for the (up to 4) busses. Establish a separate bus structure
that will hold data about each bus and use it in the control
structure. As a first usage type move the is_c45 attribute over.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
The phy_node attribute is defined per port. Move it into the new
port structure. Now it is clear that it belongs to the port.
While we are here rename it to dn (aka device_node) to align with
upstream style. As all usage locations must be adapted it makes
no sense to make two commits (relocate/rename) to change the
code twice.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
The smi_addr attribute is defined per port. Move it into the new
port structure. As the devices have a maximum of 56 addresses
save some space and convert it to type u8.
While we are here harden the mapping routine that reads these
addresses from the DTS. For this check the value that is read into
smi_addr. This is usually the MDIO standard 0..31. Sadly RTL839x
devices are an exception from that and allow addresses 0..51.
To avoid device specific if/then/else cases for now implement
a "light" consistency check.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
The smi_bus attribute is defined per port. Move it into the new
port structure. As the devices have a maximum of 4 busses save
some space and convert it to type u8.
While we are here fix a whitespace issue and rename the helper
variable in rtmdio_map_ports() to smi_bus to align with the
structure attribute.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
The raw attribute is defined per port. Move it into the new
port structure.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
The central control structure of the mdio bus holds several
attributes. These target two different objects. Some of them
are for the (up to 56) controller ports, some of them are for
the (up to 4) controller busses.
Establish a separate port structure that will hold data about
each port and use it in the control structure. As a first
usage type move the page attribute over.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22604
Signed-off-by: Robert Marko <robimarko@gmail.com>
Backport upstream driver and apply pending downstream patches to
support using the MaxLinear MxL86252 and MxL86282 switches.
The driver supports a native proprietary 8-byte DSA special tag format
(mxl862xx) as well as using an 802.1Q-based DSA tag (mxl862xx-8021q).
All basic bridge, VLAN and LAG operations are supported. A single port
can be used as mirror port. Hardware counters are made available as
ethtool stats or directly serve as interface counters (bytes,
packets).
The switch runs a complex ZephyrOS-based firmware on an integrated
ARC microcontroller, the driver uses the firmware management API over
MDIO to interact with the switch hardware.
Note that the firmware needs to be rather recent (WSP 1.0.78 or later)
to work well with this driver. It can be updated at runtime using devlink.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Use the common driver prefix for these two functions.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22610
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Check for dev in driver remove gives no additional security. The
remove() function is only called if probe() succeeded. Probing
will always call platform_set_drvdata() in the good case. So
remove() will always find dev data via platform_get_drvdata().
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22610
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The ethernet driver is only loaded via devicetree and makes use
of of_match_table. In this case the probing function is only
called if a matching compatible is set. So pdev->dev.of_node
can never be NULL.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22610
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Align the driver and matchtable naming convention to the new
rteth prefix. While we are here autogenerate the module name
by using KBUILD_MODNAME. This is common upstream practice.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22610
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Commit d52f7a4ca5 ("realtek: dts: new SWITCH_PORT_LED() macro") introduced
a new macro to simplify switch port definitions and introduces usage of
it for Zyxel XGS1X10-12 devices. However, this change added a DTS syntax
issue because:
> SWITCH_PORT_LED(...);
produces
> port@XX { ... };;
because the macro already includes a trailing semicolon. The DT compiler
doesn't like this so it fails with syntax error. Fix this by dropping the
trailing semicolons after macro usages.
Fixes: d52f7a4ca5 ("realtek: dts: new SWITCH_PORT_LED() macro")
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22614
Signed-off-by: Robert Marko <robimarko@gmail.com>
Previous changes refactored the hardware mode configuration for RTL930x
a lot. Now that this is in a better shape, one issue persists: missing
error propagation. Only parts of this function really propagate an
error, others are silently dropped. While this is a known driver-wide
issue, at least make it good here. Propagate the errors from functions
which apply configuration sequences to the caller.
Single writes are still left out on purpose, they need and will be
addressed later.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
Decommission a helper for applying config/patch sequences for even/odd
SerDes. Most of these sequences were squashed due to marginal
difference, sharing a lot of common parts. For the marginal differences,
testing showed that the different values were already present on
even/odd. Since those are no reset/trigger bits but just configuration
values, writing them for both should do no harm.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
Config/patch sequences have been reduced and merged by previous changes.
Now that we have a clearer view on them, we can see that there are still
several similarities between the even and odd variants. Some different
writes for even and odd SerDes remain but one can find out they don't
need to be separate. For example, a write to [0x29, 0x09] is missing for
odd SerDes but testing and a SerDes dump from a running configuration
show that the registers still hold the same value and changes do not
affect functionality. Thus, merge them too to get rid of a lot of
even/odd stuff.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
Right now, the config sequences for XSGMII and USXGMII have been
stripped down to their essential parts. Still, they have redundancies.
The XSGMII sequences are 99% equal to the generic ANA_10G sequences
(except for a single write which is DFE/LEQ-related and changed during
calibration later anyway), thus we can drop them completely.
The USXGMII sequences contain the same sequences so they can be removed
there too, all being covered by applying the ANA_10G sequence for those
modes too. One different write (register [0x2e, 0x01]) is integrated into
the ANA_10G sequence since testing has shown that the value is either the
default for that register anyway, or set during SDK setup too for 10GR.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
Move a few register writes from the ANA_10G patch sequences to the
configuration function. Those write are targeted at digital pages and do
not fully apply for *SGMII modes. To make the ANA_10G sequence really
just deal with analog pages and make it usable for *SGMII modes too,
move out the digital page writes.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
The patch/config sequences we took over from the SDK are partially
redundant, i.e. they share common parts which can be separated per
speed. For example, the config for 10GR contains the one for 2500Base-X
but we have a dedicated one for 2500Base-X. This is a first step to
modularize and reverse-engineer those sequences, and decrease the size
they claim.
The sequences are nearly exclusive ordered by ascending pages. This
suggests that those register/writes do not have a hidden function of
performing inline resets but rather are just configuration values.
Likely, they may be applied in rather arbitrary order. Splitting up the
sequences here assumes this is true and does some minor order changes.
Testing shows no behavioral change. Looking at [1] there are no relevant
reset or trigger bits affected by that. Suspiciously ordered writes have
mostly been kept though.
USXGMII setup needs to be adjusted too due to shared sequence parts.
[1] 82af3a36b7/sources/rtk-dms1250/include/hal/phy/rtl8295_reg_def.h
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
The patch/config sequences for USXGMII modes contain a register write
which is explicitly labelled as "enable eee". To clean the sequences and
reduce duplication, move this specific write to the USXGMII
configuration function.
While at it, demystify this register write. From [1] we can see that
only a single bit needs to be set for controlling EEE instead of the
whole register. From testing it was seen that the register has a default
value of 0x445C after reset. Thus, there is no other operation hidden in
this write and we're safe to reduce it to setting just the EEE enable
bit.
[1] 82af3a36b7/sources/rtk-dms1250/include/hal/phy/rtl8295_reg_def.h
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
USXGMII configuration is currently only performed via the patching
sequences although there's a dedicated function which configures several
parameters and assigns meaningful names to some register fields. It was
introduced in dca20f91ea ("realtek: add serdes patch for 10G_QXGMII")
but somewhat abandoned later due to a partial revert.
To improve the situation, prioritize usage of the function for USXGMII
variants and remove some parts from the patch sequences which seem to be
exclusive for USXGMII and thus can be covered by this function. Writes
to registers [0x6, 0xE], [0x6, 0x13] and [0x6, 0x14] can be dropped
completely because they are redundant. The bits really affected by
these writes (compared to the default register values aquired from a
dump) are overwritten below again. Testing on real hardware and USXGMII
supports this.
While at it, improve the style a bit and add comments explaining some of
the fields a bit more. Additionally, fix the call situation which
currently is dead code due to early exit. Provide two calls to the
mentioned functions but comment one of them to remain current
functionality. Names and meaning of fields is inferred from [1].
[1] 82af3a36b7/sources/rtk-dms1250/include/hal/phy/rtl8295_reg_def.h
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
Start deconstructing the patch/config sequences by carving out two
specific writes which are common for non-USXGMII and are special because
they are not in analog SerDes pages.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
Handle QSGMII config earlier within the configuration function as a
preparation for subsequent patches in this area. Those will target
splitting up the config sequences and 5G-QSGMII is special there.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
Rename the function that currently "applies patches" so that it covers
everything it does (and will do). It doesn't only apply patches but in
general performs configuration of a SerDes for a particular hardware
mode.
While at it, remove a print above that call because it is both placed
wrong and redundant due to what the generic pcs_config prints.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
Change how patches are applied to reduce redundancy and make the code
more readable. Define a generic function that applies any patch. Within
the RTL930x patch application, define a local macro that helps to get
rid of repeated even/odd checks. While making the code cleaner, it is
also a preparation for further refactoring here.
This adds a local helper macro intended to be only temporary but keeps
the style of the code clean by avoiding a lot of if-else clauses.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/22582
Signed-off-by: Robert Marko <robimarko@gmail.com>
Several devices (including the upcoming DGS-1250) need a fully
featured port definition that includes:
- port number
- label
- led-set
- pcs-handle
- phy-handle
- phy-mode
Provide a new macro for that and make the Zyxel XGS-1210 series
the first consumer of it.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22591
Signed-off-by: Robert Marko <robimarko@gmail.com>
Allow to configure the LM75 alert pin to active-high instead
of its default active-low. This patch is needed for the D-Link
DGS-1250 series where the alert pin steers the fan speed
between low and high.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22589
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
When the link goes down on the other end of a bond, it was noticed that the
switch was still trying to send data over this link.
Problem here is that net_lag_port_dev_txable() uses
bond_is_active_slave_dev() to look the state up. But this is actually
showing if a link is a NOT a backup - not if the link should be really be
TX enabled or not.
As a DSA driver, it is important to consume the DSA information.
dp->lag_tx_enabled must therefore be used for DSA .port_lag_change events.
This variable contains two information from the
struct netdev_lag_lower_state_info:
tx_enabled = linfo->link_up && linfo->tx_enabled;
Fixes: 89322b4d69 ("rtl93xx: dsa: Handle lag_change properly")
Signed-off-by: Sven Eckelmann <se@simonwunderlich.de>
Link: https://github.com/openwrt/openwrt/pull/22382
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The RTL93xx based D-Link DGS-1250 series is currently being
prepared for OpenWrt support. These devices have some extras
that are not yet supported by the existing configuration.
Add the following items to the kernel configuration:
- CONFIG_SENSORS_GPIO_FAN: The devices have a simple gpio
controlled fan (0/1 aka off/on).
- CONFIG_I2C_GPIO_SHARED: The busses of the SFP+ slots are
not controlled by the built-in SOC I2C controller. Instead
they are realized by shared SCL bit banged GPIOs.
- CONFIG_EEPROM_AT24: The MAC address and other device data
is storend in an Atmel EEPROM.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22543
Signed-off-by: Robert Marko <robimarko@gmail.com>
The i2c-shared-gpio driver is designed to emulate up to four
i2c busses with distinct sda lines and a a shared scl line.
For some reason the check for the number of allowed busses
is one off and the driver can only allocate three busses.
Fix that.
Fixes: acd7ecc9ed ("realtek: add new i2c-gpio-shared driver")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22543
Signed-off-by: Robert Marko <robimarko@gmail.com>
Due to the last refactorings it has become clear that the following
code is wrong.
static void rteth_tx_timeout()
{
...
rteth_838x_hw_en_rxtx(ctrl);
A generic function must not call a device specific function directly.
Make hw_en_rxtx() a config member and call that instead of the
functions directly.
With this change another optimization can take place. hw_init()
currently calls device specific hw_en_rxtx() functions at the start
of the function. This is wrong. Initialize the hardware first before
activating the network rx/tx. Take out the multiple calls and place
the rx/tx setup just before the hw_init() call.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22421
Signed-off-by: Robert Marko <robimarko@gmail.com>
The RTL839x notify ring buffer setup is the last consumer
of family_id. Convert it to a device specific callback and
drop family_id from the configuration structure.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22421
Signed-off-by: Robert Marko <robimarko@gmail.com>
Split rteth_93xx_hw_en_rxtx() into two device specific
functions to avoid family_id checks.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22421
Signed-off-by: Robert Marko <robimarko@gmail.com>
RTL93xx sets up the ring counters twice. One location is
inside rteth_93xx_hw_en_rxtx() and the other one is inside
rteth_93xx_hw_reset(). There are slight differences (e.g.
the ring size that is set or how the counters are cleared).
It is currently unclear where to place it best. For now
align this to RTL83xx and remove the coding from function
rteth_93xx_hw_en_rxtx(). Provide a complete & proper setup
in rteth_93xx_hw_reset().
Looking at the different old implementations one can see
that one initialized the ring counters with offset "-2".
This headroom is not needed. The old comment " Some SoCs
have issues with missing underflow protection" was only
regarding the way the counters are being resetted and not
how large they are setup.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22421
Signed-off-by: Robert Marko <robimarko@gmail.com>
Remove another family check inside rteth_open() and split it
out into device specific hw_init() helper functions.
RTL93xx still use a common rteth_93xx_hw_en_rxtx() helper.
That will be split later.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22421
Signed-off-by: Robert Marko <robimarko@gmail.com>
The hw_en_rxtx() functions still use the old prefix. Rename
them to align with the rest of the code. This refactoring
makes clear that there is a bug in rteth_tx_timeout(). A
generic function should not call a device specific function
directly. The bug will be fixed separately.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22421
Signed-off-by: Robert Marko <robimarko@gmail.com>
The hw_stop() function uses multiple family checks to determine
what needs to be done. Split that into device specific helpers
to simplify the code.
For further simplification common parts of the stop functions
have been kept in rteth_hw_stop().
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22421
Signed-off-by: Robert Marko <robimarko@gmail.com>
rtl838x_hw_stop() still uses the old prefix. Change it "rteth"
and make clear that this is a generic function for all targets.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22421
Signed-off-by: Robert Marko <robimarko@gmail.com>
The build system currently issues the following warnings.
../dts/rtl9303_xikestor_sks8300-8t.dts:57.4-17: Warning (reg_format):
/switchcore@1b000000/i2c@36c/i2c@0/temperature-sensor@48:reg: property
has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
Fix that by providing proper cell data.
Fixes: c63433acd ("add support for XikeStor SKS8300-8T")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22593
Signed-off-by: Robert Marko <robimarko@gmail.com>
The build system currently issues the following warnings.
../dts/rtl9303_xikestor_sks8310-8x.dts:141.4-17: Warning (reg_format):
/switchcore@1b000000/i2c@36c/i2c@0/sensor@48:reg: property has invalid
length (4 bytes) (#address-cells == 2, #size-cells == 1)
Fix that by providing proper cell data.
Fixes: 4a73f72a2 ("add monitor IC node for XikeStor SKS8310-8X")
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22593
Signed-off-by: Robert Marko <robimarko@gmail.com>
The Netgear GS110TPP uses an RTL8214C to drive ports 9 and 10. The
DTS is missing the corresponding serdes assignment. From looking at
[1] it seems to be connected to pins 82-85 (serdes 2). Add that
definition. With that the last improper use of SWITCH_PORT() macro
is sorted out.
Remark: I do not own this device. The patch just resembles what
the picture [1] shows.
[1] https://svanheule.net/switches/_media/wiki/gs110tpp-top.jpg
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22232
Signed-off-by: Robert Marko <robimarko@gmail.com>
When the fan control script was first implemented, a variable was wrongly
named. The fan probably never turns on - fix that.
Signed-off-by: Andreas Böhler <dev@aboehler.at>
Link: https://github.com/openwrt/openwrt/pull/22531
Signed-off-by: Robert Marko <robimarko@gmail.com>
Rename smi_bus_isc45 to smi_bus_is_c45 for better readability.
Upstream uses same naming convention.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22565
Signed-off-by: Robert Marko <robimarko@gmail.com>
Harden the mdio driver probing by checking for duplicate port
definitions. Now that the driver has a valid_port mask this
is just a simple bit check. This is the same as upstream does.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22565
Signed-off-by: Robert Marko <robimarko@gmail.com>
Until now the driver determines the validity of a phy (or port)
by checking "smi_bus[] < 0". That is somehow confusing. Align
with upstream and add a valid_port bitmask that can be used for
this check with common kernel bit operations.
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Link: https://github.com/openwrt/openwrt/pull/22565
Signed-off-by: Robert Marko <robimarko@gmail.com>
