The i.MX8MP and i.MX95 USB3 PHY have different tuning parameter for same
tuning field, this will add i.MX95 tuning support.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>
The description of TX_VBOOST_LVL is wrong in register PHY_CTRL3
bit[31:29].
The updated description as below:
011: Corresponds to a launch amplitude of 0.844 V.
100: Corresponds to a launch amplitude of 1.008 V.
101: Corresponds to a launch amplitude of 1.156 V.
This will fix the parsing function
phy_tx_vboost_level_from_property() to return correct value.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>
When enable initcall_debug together with higher debug level below.
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=9
CONFIG_CONSOLE_LOGLEVEL_QUIET=9
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7
The initialization of i.MX8MP PCIe PHY might be timeout failed randomly.
To fix this issue, adjust the sequence of the resets refer to the power
up sequence listed below.
i.MX8MP PCIe PHY power up sequence:
/---------------------------------------------
1.8v supply ---------/
/---------------------------------------------------
0.8v supply ---/
---\ /--------------------------------------------------
X REFCLK Valid
Reference Clock ---/ \--------------------------------------------------
-------------------------------------------
|
i_init_restn --------------
------------------------------------
|
i_cmn_rstn ---------------------
-------------------------------
|
o_pll_lock_done --------------------------
Logs:
imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000
probe of clk_imx8mp_audiomix.reset.0 returned 0 after 1052 usecs
probe of 30e20000.clock-controller returned 0 after 32971 usecs
phy phy-32f00000.pcie-phy.4: phy poweron failed --> -110
probe of 30e10000.dma-controller returned 0 after 10235 usecs
imx6q-pcie 33800000.pcie: waiting for PHY ready timeout!
dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2)
imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110
Fixes: dce9edff16 ("phy: freescale: imx8m-pcie: Add i.MX8MP PCIe PHY support")
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <frank.li@nxp.com>
commit ce52c25322 upstream.
According to fsl,imx8mq-usb-phy.yaml, this tuning parameter should be
fsl,phy-pcs-tx-deemph-3p5db-attenuation-db.
Fixes: 63c85ad0cd ("phy: fsl-imx8mp-usb: add support for phy tuning")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://lore.kernel.org/r/20240801124642.1152838-1-xu.yang_2@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1000Base-KX lanes need a 312.5 MHz clock for backplane auto-negotiation.
The reference manual suggests to generate this frequency from the PLL's
FRATE_SEL/16, through the ex_dly_clk mechanism (note: we know that
FRATE_SEL must be 5 GHz for 1000Base-KX, as for all other 1G protocols).
The ex_dly_clk is used on some SoCs for other stuff as well: for example
on LS1028A, it is used to derive the SYS_CLK for the Felix Ethernet
switch when that has 1G SGMII or QSGMII lanes. For other SerDes
protocols, the switch SYS_CLK is derived from other places. But when it
comes from ex_dly_clk, the RCW will automatically set PLLnCR0[DLYDIV_SEL]
to 1.
To cope with that case, we bake logic into the driver to bump the usage
count of ex_dly_clk at driver probe time. This way, it never really
drops to zero even after all lanes went to 1000Base-KX and back to
something else.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Dynamic SerDes protocol changing has been tested using C73
auto-negotiation and it works, so remove the restriction.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
lynx_10g_switch_needs_rcw_override() determines whether the switchover
takes place between any 1G and 2.5G Ethernet lane mode, because those
don't require RCW override.
1000Base-KX is backplane Ethernet at 1G, and therefore it should also
be in this list, because no RCW override of the SerDes protocol is
necessary when switching to it from 1000Base-X, SGMII, or 2500Base-X.
This matters because some SoCs (like LS1028A) do not have RCW override
at all, and thus they error out on this check when enabling 1000Base-KX,
which is absolutely unnecessary.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The 1000Base-KX AN/LT block requires a 312.5 MHz clock to be generated
by the SerDes PLL (clock net 5 GHz / div 16).
Code up a scheme through which PLLnCR1[EX_DLY_DIV] is monitored, and is
kept enabled as long as lanes exist in the 1000Base-KX mode.
I examined the possibility of having Linux keep the PLL as purely
read-only and enabling EX_DLY_CLK from the PBL (Pre-Boot Loader).
The only problem with that has to do with (in)elegant scaling.
Since the PBL can only do writes, it cannot perform a read-modify-write
operation on PLLnCR1, so it has to make assumptions about the values of
the other existing fields in that register. That's kinda complicated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Dynamic SerDes protocol changing has been tested with C73
auto-negotiation and it works. We can remove the restriction.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
There are 3 SerDes blocks on LX2160A and 2 on LX2162A, and they differ
in some aspects, namely in the number of lanes per SerDes and in the
protocol converters instantiated per lane.
All of this justifies introducing compatible strings for each SerDes and
some driver structures for figuring out the differences. The
"fsl,lynx-28g" compatible string is kind of the "maximal configuration".
It corresponds to SerDes 1 of LX2160A. If we were to treat all SerDes
blocks like this one, we would access lanes which do not exist (0-3) and
we would fail to reject lane modes which don't work.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The current approach of transitioning from one SerDes protocol to
another in lynx_28g_set_lane_mode() is too poetic.
We need something more systematic to make sure that all lane and
protocol converter registers are written to consistent values, no matter
what was the source lane mode.
For that, we need to introduce tables with register field values, for
each supported lane mode.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
We cannot (at the moment, at least) change between, say, 10GBase-KR and
40GBase-KR4. There exists the single lane->supported_backplane_mode
limitation which prevents that, but we'd like to remove it to permit
multiple backplane modes at the same time, so we need a better
restriction in place.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
We need to distinguish between the backplane mode 40GBase-KR and the
non-backplane 40GBase-R. The SerDes lane is not configured for backplane
by default, and thus, if we say that the initial mode is 40GBase-KR,
then this check from phy_set_mode_ext() will leave the lane unconfigured
even after that call:
if (lane_mode == lane->mode)
return 0;
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Currently it is possible that the state of a failed link training
sequence lingers (is preserved) onto the next link training attempt.
That is not okay and we should reset the state so that we always start
from a consistent position.
This is not possible with the current API, because the backplane AN/LT
module actually never explicitly tells the SerDes PHY that a new
training sequence has begun, and we cannot infer that from C72_LT_DONE
means "done successfully". We need to introduce a command specific to
that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Some SerDes protocols like QSGMII or 10G-QXGMII are multi-port - that
is, they multiplex multiple protocol converters onto the same SerDes
lane (PHY).
The question "what is the address of this lane's protocol converter?" as
asked by PHY_STATUS_PCVT_ADDR is nonsensical in such a case, because
there are multiple converters, and it is not clear which one is being
querier.
So far we've only been using PHY_PCVT_ETHERNET_ANLT (which indeed is at
most one per lane) and not PHY_PCVT_ETHERNET_PCS where the problem truly
lies. But we have to add more API to query the protocol converter count,
and then query the addresses of individual protocol converters for the
currently configured PHY mode.
Fix the PHY API, Lynx SerDes drivers and MTIP backplane AN/LT consumer
all in one go.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
ISI driver system resume will fail while streaming, log as bellow:
[ 41.046643] mxc-isi 4ad50000.isi: Failed to enable pipe 0
[ 41.052089] mxc-isi 4ad50000.isi: Failed to resume pipeline 0 (-13)
[ 41.058387] mxc-isi 4ad50000.isi: PM: dpm_run_callback(): mxc_isi_pm_resume+0x0/0xdc returns -13
[ 41.067213] mxc-isi 4ad50000.isi: PM: failed to resume: error -13
The reason is the ISI, CSI and MIPI DPHY driver suspend/resume
sequence. When system enter suspend state, the sequence is CSI
-> ISI -> DPHY and the order is reversed while resume. During ISI
resume, it will recover pipeline state and enable streams of all
subdevice, but CSI still not resume, so it can't enable stream
which cause ISI enable pipeline failure.
Moving get phandler of CSI from probe to phy_init callback to
change the sequence to ISI -> CSI -> DPHY.
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
Reviewed-by: Sandor Yu <Sandor.yu@nxp.com>
In order to implement support for combo phy (which is an RX/TX phy),
we also need access to the DSI memory space (which uses the phy as TX)
to program the TX registers of the combo phy in the same time while we
program the RX registers to configure the phy in slave mode, for RX,
required by CSI.
Signed-off-by: Robert Chiras <robert.chiras@nxp.com>
Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
When orientation is TYPEC_ORIENTATION_NONE, let tca enter into low power
mode and put phy into USB safe state.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmZu0U0ACgkQONu9yGCS
aT4c2Q//SGn9+yEUml1/7nQUTND434ly4JPMdrR1jjJSKwxAsgzOYKCoUpzpXim8
7mdKz7q1cXx/l+tfJgEDdJ8JzVS6ipJWAwF4vE+18zWZjEax/M3dgluZUUswXKYg
Da76wSaNkfGiIewu8HV90LKAKaQoCR4ypyWG8CqDZkCnGJORUJA09GNDrKFhOodT
f0TzjIvPw8E3rU2+HZfPmxUI0XQEzfVPWb5DK+0F7hcHw4ETcij7y0AInBkQ5bNt
tFRCc462nT23e3jXJECWMbSXdRF57LlT8G9626Om0iS+TY7YD6PPNa7/bdqVHzcw
hDmKE+xONslwvuzkYn2R9u+nc/dw/hJ8QI5j9QohbJCcXjcv8N3QeXoiLPjiDxxv
1JVVi6emyKvKx26kjY/m0ZTZ/QWWwQlj/+R8Or/yIMMYZvPwyBUX3I8cZIQhyAg4
n/fc2tFqmax0K6e9YOXj3sa+OlXx02DAC8oVToNrSS7HT5uhtoKT4vU1d+et2alo
dFJAhklt27k+eV+Ayxo+RUaxUVggM0MAB67S7XUR0kylP2BeL2l9wMKVzZz2V5T4
O9PHY1RpD8OGk7aZvlbZYIis7LBqVTXcaEB4l5QtSYM4RMON4BYb5QLEc0jYywzV
U7GMNiKhhuwEHjiPD0cIXyeWeQzTlH9os5lhW8moVY9mtthGlr0=
=zdH0
-----END PGP SIGNATURE-----
Merge tag 'v6.6.34' into lf-6.6.y
This is the 6.6.34 stable release
* tag 'v6.6.34': (2530 commits)
Linux 6.6.34
smp: Provide 'setup_max_cpus' definition on UP too
selftests: net: more strict check in net_helper
...
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Conflicts:
arch/arm64/boot/dts/freescale/imx8-ss-conn.dtsi
drivers/net/ethernet/freescale/fec_ptp.c
drivers/pmdomain/imx/imx8mp-blk-ctrl.c
drivers/usb/dwc3/host.c
tools/perf/util/pmu.c
While bringing down a backplane port, it might happen that the system
hangs in a tight loop with IRQs disabled, thus triggering an RCU stall
and killing the machine, as seen below.
$ ifconfig eth1 down
fsl_dpaa2_eth dpni.3 eth1: Link is Down
mdio_bus 0x0000000008c27000:00: AN did not complete after link training completed
fsl_dpaa2_eth dpni.2 eth2: Link is Down
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 0-....: (5249 ticks this GP) idle=cbe4/1/0x4000000000000000 softirq=1703/1703 fqs=2625
(t=5252 jiffies g=7993 q=244 ncpus=16)
CPU: 0 PID: 1225 Comm: kworker/0:0 Not tainted 6.1.36 #1
Workqueue: events mtip_irqpoll_work
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : lynx_28g_cdr_lock_check.isra.14+0x94/0xb8
lr : lynx_28g_get_status+0x78/0x278
Call trace:
lynx_28g_cdr_lock_check.isra.14+0x94/0xb8
phy_get_status+0x58/0x90
mtip_check_cdr_lock+0x48/0x108
mtip_irqpoll_work+0x80/0x878
process_one_work+0x204/0x3c0
worker_thread+0x258/0x508
kthread+0xdc/0xe8
ret_from_fork+0x10/0x20
It looks possible for phy_get_status() in that code path to be called
even after the mtip_backplane_suspend() -> phy_power_off(). But in that
case, LNaRRSTCTL_RST_DONE will never set. So the tight loop with no
timeout will hang the system.
From lynx_28g_cdr_lock_check_work() we do check that the lane has been
powered up, but that's just one caller of lynx_28g_cdr_lock_check().
We need to add one more such test inside lynx_28g_cdr_lock_check()
itself, which avoids a reset if powered down when called from
lynx_28g_snapshot_rx_eq() or lynx_28g_check_cdr_lock().
Fixes: 375b57c1a9 ("phy: lynx-28g: truly power the lanes up or down")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Add support for the RCW override procedure which enables runtime
reconfiguration of the protocol running on a SerDes lane. The procedure
is done through the DCFG DCSR space which now can be defined as the
second memory region of the guts DT node.
Support is added on the following SoCs: LS1046A, LS1088A, LS2088A.
The procedure is exported to the "client" driver - the Lynx10G SerDes
PHY driver - through the following functions:
- fsl_guts_lane_init() used to notify the initial / at boot time lane
mode running on a SerDes lane.
- fsl_guts_lane_validate() used to validate that changing the protocol
on a specific lane is supported.
- fsl_guts_lane_set_mode() which can be used to request the RCW
procedure be executed for a specific lane.
The necessary changes in the Lynx10G SerDes driver are also implemented
in this patch.
Since the RCW override procedure is different depending on the SoC, the
private fsl_soc_data structure is updated with two new per SoC callbacks
(.serdes_get_rcw_override() and .serdes_init_rcwcr()) which get used
from the generic fsl_guts_lane_set_mode() function. These two callbacks
hide all the SoC specific register offsets, masks and values so that the
_set_mode() procedure is straightforward.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
The lynx_lane_mode enum will need to be used from the fsl_guts driver in
order to do the RCW override procedure for a specific Lynx10G link mode.
Since we need the enum into a public header file, create the
phy-fsl-lynx.h header for this purpose.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Add a new field to struct lynx_info to be able to identify precisely the
Lynx10G block index. This will get used in the next patches which do RCW
override.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Fix below build error when building it as a module:
drivers/phy/freescale/phy-fsl-imx9-dphy-rx.c:463:25: error: use of
undeclared identifier 'dw_dphy_rx_of_match';did you mean 'dw_dphy_of_match'
MODULE_DEVICE_TABLE(of, dw_dphy_rx_of_match);
Signed-off-by: Jindong Yue <jindong.yue@nxp.com>
Reviewed-by: G.N. Zhou <guoniu.zhou@nxp.com>
TCA is a Type-C assist block in i.MX95 USB3 phy. The TCA block consists
of two functional blocks (XBar assist and VBus assist) and one system
access interface using APB.
The primary functionality of XBar assist is:
- switching lane for flip
- moving unused lanes into lower power states.
This driver will mainly focus on the lane switching functionality.
Note: this version will not put SS lane into USB safe state since the host
controller cannot be reset when SS lane is in USB safe state.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Check the return value and don't print error message when return
error is -EPROBE_DEFER to avoid confusion.
Signed-off-by: Guoniu.zhou <guoniu.zhou@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
* net/next: (344 commits)
LF-10639-5 net: enetc: Add xpcs support and set 10G support bits
LF-10639-4 net: pcs: xpcs: add mx95 serdes support
LF-10640-6 ptp: add NETC PTP driver support for i.MX95
LF-10639-3 net: phy: aquantia: enable LEDs to show the link state
LF-10639-1 enetc: mdio: add regulator support for both imdio and emdio bus
...
Fix the following bugs in the 'fsl,ls1088a-serdes1':
- Remove the LANE_MODE_2500BASEX mode since this is not listed in the
SoC RM as a support mode.
- Mark the XFI protocol converter as being available on lanes #2 and #3.
- Remove a forgotten 'return' statement from the
ls1088a_serdes1_get_pcvt_offset() function.
This driver was tested on the LS1088ARDB board with the following
protocols: 10GBASER, 1000BASE-X/SGMII and QSGMII. As such, mark the SoC
as tested.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
The 'fsl,ls2088a-serdes1' compatible handling was tested in a copper
backplane scenario. Remove the comment saying otherwise.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
lynx_pccr_read() may return -EOPNOTSUPP if the representation of the SoC
integration that is hardcoded in the driver - priv->info->get_pccr() -
does not expect there to exist a PCCR register for a given lane and
SerDes protocol.
In lynx_10g_backup_pccr_val(), we are ignoring that negative error code
on good faith, which means that the way in which the hardware is
configured at probe time will never take us by surprise.
Given the fact that we issue no hardware reset to the SerDes on probe,
it can happen that someone has messed with the lane configuration in an
invalid way during a prior boot stage (e.g. PBL), forcing a protocol
selection in LNaPSSR0_TYPE for which we have no actual protocol converter.
What would happen in that case is that we would happily ignore the
-EOPNOTSUPP from lynx_pccr_read() and proceed to save an uninitialized
"u32 val" as lane->default_pccr, and continue on, thinking this lane is
OK to be used.
What we should probably do instead is to mark the lane as having an
unknown protocol, because we don't expect it to be configured that way,
and produce a warning.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The blamed commit introduced a phy_exit() call which was missing before,
to lynx_pcs_destroy(). The role of phy_exit() is to bring the
phy->init_count from the phy core back to 0, so that a subsequent
phy_init() call gets propagated to the driver again.
What was happening is that when the dpaa2-mac driver had -EPROBE_DEFER
and it called phy_init() a second time, that didn't get propagated to
the driver, since the phy->init_count would just get bumped to 2.
That is no longer the case - we call phy_init() each time, but the Lynx
hardware is not prepared to power down a powered down lane. Instead, the
driver just hangs in the loop that expects the power down operation to
finalize.
Fix that by implementing phy_exit() as the operation which powers the
lane back up - essentially the expected operation when it is not managed
by a consumer, but operating as standalone.
Fixes: 7a560782c9 ("net: pcs: lynx: incorporate SerDes PHY handling from dpaa2-mac")
Debugged-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The blamed commit introduced a phy_exit() call which was missing before,
to lynx_pcs_destroy(). The role of phy_exit() is to bring the
phy->init_count from the phy core back to 0, so that a subsequent
phy_init() call gets propagated to the driver again.
What was happening is that when the dpaa2-mac driver had -EPROBE_DEFER
and it called phy_init() a second time, that didn't get propagated to
the driver, since the phy->init_count would just get bumped to 2.
That is no longer the case - we call phy_init() each time, but the Lynx
hardware is not prepared to power down a powered down lane. Instead, the
driver just hangs in the loop that expects the power down operation to
finalize.
Fix that by implementing phy_exit() as the operation which powers the
lane back up - essentially the expected operation when it is not managed
by a consumer, but operating as standalone.
Fixes: 7a560782c9 ("net: pcs: lynx: incorporate SerDes PHY handling from dpaa2-mac")
Debugged-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Introduce a driver for the networking lanes of the Lynx 10G block,
present on the majority of Layerscape and QorIQ (Freescale/NXP) SoCs.
Co-developed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Allow consumers of the SerDes lane to figure out the PCS and AN/LT block
address without hardcoding it in the device tree or in the driver code,
which is what they do currently.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Application note AN12950 recommends certain default SerDes lane values
to be changed for 25G Ethernet. The workaround is implemented in the
Pre-Boot Loader (PBL).
However, the SerDes driver overwrites what the PBL does. So it needs to
be aware of those special values too.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Provide an implementation for the new phy_configure_opts_xgkr API for
the 28G Lynx SerDes from NXP LX2160A. The core logic of the algorithm is
also usable with the 10G Lynx SerDes for earlier QorIQ/Layerscape SoCs,
but a driver does not exist for that yet. Nonetheless, it is in progress,
so structure the link training algorithm as library code, shareable by
the two SerDes drivers when the time comes.
Loosely based on previous work by Florinel Iordache.
Co-developed-by: Florinel Iordache <florinel.iordache@nxp.com>
Signed-off-by: Florinel Iordache <florinel.iordache@nxp.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The Lynx 28G SerDes lanes allow the tuning of their signal equalization
parameters as required by the IEEE 802.3 clauses for copper backplanes.
These modes are selected when there is a backplane AN/LT block in charge,
and it uses phy_set_mode_ext(PHY_MODE_ETHERNET_LINKMODE).
Only the single-lane link modes (1000Base-KX, 10GBase-KR, 25GBase-KR)
are supported here (40GBase-KR, 100GBase-KR - not yet). And only the
initial configuration for these link modes is present, not the dynamic
equalization changes. That will come as a separate change.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The future XGKR algorithm implementation will want to perform an
expedited CDR lock check. Rename the work item, and move the core logic
to a dedicated function that can be reused.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The driver will need to become more careful with the values it writes to
the TX and RX equalization registers. As a preliminary step, convert the
magic numbers to macros defining the register field meanings.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
The driver does not handle well protocol switching to or from USXGMII,
because it conflates it with 10GBase-R.
In the expected USXGMII use case, that isn't a problem, because SerDes
protocol switching performed by the lynx-28g driver is not necessary,
because USXGMII natively supports multiple speeds, as opposed to SFP
modules using 1000Base-X or 10GBase-R which require switching between
the 2.
That being said, let's be explicit, and in case someone requests a
protocol change which involves USXGMII, let's do the right thing.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
In preparation for PHY_MODE_ETHTOOL support in the lynx-28g phy driver,
we need a unified internal data type for the lane operating modes.
That can be neither phy_interface_t nor ethtool_link_mode_bit_indices.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
