| Age | Commit message (Collapse) | Author |
|---|
|
Writing of individual registers was not functioning
correctly as a 0 'offset' byte under DM-managed
I2C was being appended in front of register we
wanted to access.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
|
|
The RX8025/RX8035 does not like having it's time registers
set byte-by-byte in separate I2C transactions.
From the note at the top of the file, it appears
target-dependent workarounds have been used in the
past for this.
Resolve this by setting the time registers in a single
I2C transaction.
As part of this, also ensure the '24/12' flag in the RTC
is reset before writing the date (instead of after), otherwise
the RX8035 will clear the seconds and minutes registers.
Tested on Traverse Ten64 (NXP LS1088A) with RX8035.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
|
|
The RX8035 is a newer model from EPSON which is
very similar in operation to the RX8025.
The changes mirror similar ones that will be
in Linux 5.15:
https://lore.kernel.org/all/20210709044518.28769-2-matt@traverse.com.au/
The UBOOT_DRIVER ID has also been corrected, previously
it declared itself as rx8010sj_rtc which is a different driver.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
|
|
A search of the tree showed there is only one user
of this driver (soon to be two) - board/socrates
The second user will be the Traverse Ten64 board.
Both these boards have DM_RTC.
Signed-off-by: Mathew McBride <matt@traverse.com.au>
|
|
We enforce that DM_SERIAL will have SYS_MALLOC_F enabled and so
SYS_MALLOC_F_LEN will have a value. Remove the build-time check.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This board has not been converted to CONFIG_DM by the deadline.
Remove it. As this is the last ARCH_MX25 platform, remove those
references as well.
Cc: Matthias Weisser <weisserm@arcor.de>
Cc: Stefano Babic <sbabic@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This board has not been converted to CONFIG_DM by the deadline.
Remove it. As this is the last armada100 platform, remove that support
as well.
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
This board has not been converted to CONFIG_DM by the deadline.
Remove it. As this is the last mx35 platform, remove that support as
well.
Cc: Stefano Babic <sbabic@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Stefano Babic <sbabic@denx.de>
|
|
https://source.denx.de/u-boot/custodians/u-boot-microblaze into next
Xilinx changes for v2022.01-rc1
zynq:
- Enable capsule update for qspi and mmc
- Update zed DT qspi compatible string
zynqmp:
- Add missing modeboot for EMMC
- Add missing nand DT properties
- List all eeproms for SC on vck190
- Add vck190 SC psu_init
clk:
- Handle only GATE type clock for Versal
watchdog:
- Update versal driver to handle system reset
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
Signed-off-by: Wolfgang Denk <wd@denx.de>
|
|
Wdt expire command makes the wdt to count least possible ticks(1)
and expires immediately. Add expire_now option to the xlnx_wwdt_ops
and implement it by calling xlnx_wwdt_start() with minimum possible
count(1).
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Link: https://lore.kernel.org/r/1632808919-8600-3-git-send-email-ashok.reddy.soma@xilinx.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
Existing driver uses generic watchdog mode which generates a signal to
PLM firmware, but the signal cannot be used to reset the system.
Change driver to use window watchdog basic mode. This window watchdog mode
generates a signal to PLM firmware which decides what action to take upon
expiry of watchdog.
Timeout value for xlnx_wwdt_start will come in milli seconds from wdt
framework. Make changes to load count value accordingly.
Add checks before loading the timer for min and max possible values.
Fix authour email id of Ashok Reddy Soma to long email id.
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Link: https://lore.kernel.org/r/1632808919-8600-2-git-send-email-ashok.reddy.soma@xilinx.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
Clocks should be enabled or disabled only if they are of GATE type
clocks. If they are not of GATE type clocks, don't touch them.
Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com>
Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Link: https://lore.kernel.org/r/1632808827-6109-1-git-send-email-ashok.reddy.soma@xilinx.com
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
https://source.denx.de/u-boot/custodians/u-boot-net into next
- Fix some non-NULL terminated strings in the networking subsystem
- net: tsec: Mark tsec_get_interface as __maybe_unused
|
|
- Start moving some TI board docs to rST
- Assorted TI-specific Kconfig migrations and namespace cleanups. This
also allows for some code cleanups.
|
|
nand_dt_init() is still using fdtdec_xx() interface.
If OF_LIVE flag is enabled, dt property can't be get anymore.
Updating all fdtdec_xx() interface to ofnode_xx() to solve this issue.
For doing this, node parameter type must be ofnode.
First idea was to convert "node" parameter to ofnode type inside
nand_dt_init() using offset_to_ofnode(node). But offset_to_ofnode()
is not bijective, in case OF_LIVE flag is enabled, it performs an assert().
So, this leads to update nand_chip struct flash_node field from int to
ofnode and to update all nand_dt_init() callers.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
|
|
Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
silently defaulted to SF bus mode 0. Now the mode is always updated,
which causes breakage. It seems most SF which are used as boot media
operate in bus mode 0, so switch that as the default.
This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
as those might need mode 3.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Aleksandar Gerasimovski <aleksandar.gerasimovski@hitachi-powergrids.com>
Cc: Andreas Biessmann <andreas@biessmann.org>
Cc: Eugen Hristev <eugen.hristev@microchip.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Siew Chin Lim <elly.siew.chin.lim@intel.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Valentin Longchamp <valentin.longchamp@hitachi-powergrids.com>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
|
|
Force the mtd name of spi-nor to "nor" + the driver sequence number:
"nor0", "nor1"... beginning after the existing nor devices.
This patch is coherent with existing "nand" and "spi-nand"
mtd device names.
When CFI MTD NOR device are supported, the spi-nor index is chosen after
the last CFI device defined by CONFIG_SYS_MAX_FLASH_BANKS.
When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated, this config
is replaced by to cfi_flash_num_flash_banks in the include file
mtd/cfi_flash.h.
This generic name "nor%d" can be use to identify the mtd spi-nor device
without knowing the real device name or the DT path of the device,
used with API get_mtd_device_nm() and is used in mtdparts command.
This patch also avoids issue when the same NOR device is present 2 times,
for example on STM32MP15F-EV1:
STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, \
total 64 MiB
List of MTD devices:
* nand0
- type: NAND flash
- block size: 0x40000 bytes
- min I/O: 0x1000 bytes
- OOB size: 224 bytes
- OOB available: 118 bytes
- ECC strength: 8 bits
- ECC step size: 512 bytes
- bitflip threshold: 6 bits
- 0x000000000000-0x000040000000 : "nand0"
* mx66l51235l
- device: mx66l51235l@0
- parent: spi@58003000
- driver: jedec_spi_nor
- path: /soc/spi@58003000/mx66l51235l@0
- type: NOR flash
- block size: 0x10000 bytes
- min I/O: 0x1 bytes
- 0x000000000000-0x000004000000 : "mx66l51235l"
* mx66l51235l
- device: mx66l51235l@1
- parent: spi@58003000
- driver: jedec_spi_nor
- path: /soc/spi@58003000/mx66l51235l@1
- type: NOR flash
- block size: 0x10000 bytes
- min I/O: 0x1 bytes
- 0x000000000000-0x000004000000 : "mx66l51235l"
The same mtd name "mx66l51235l" identify the 2 instances
mx66l51235l@0 and mx66l51235l@1.
This patch fixes a ST32CubeProgrammer / stm32prog command issue
with nor0 target on STM32MP157C-EV1 board introduced by
commit b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when
DM is enabled").
Fixes: b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM is enabled")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
[trini: Add <dm/device.h> to <mtd.h> for DM_MAX_SEQ_STR]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
These functions can return errors, it's best to catch them and trigger
the driver unwind code path.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
MDIO_NAME_LEN truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
MDIO_NAME_LEN truncation
strncpy() simply bails out when copying a source string whose size
exceeds the destination string size, potentially leaving the destination
string unterminated.
One possible way to address is to pass MDIO_NAME_LEN - 1 and a
previously zero-initialized destination string, but this is more
difficult to maintain.
The chosen alternative is to use strlcpy(), which properly limits the
copy len in the (srclen >= size) case to "size - 1", and which is also
more efficient than the strncpy() byte-by-byte implementation by using
memcpy. The destination string returned by strlcpy() is always NULL
terminated.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
The two should be equivalent, but at the moment some platforms
(ls1021a-tsn.dts) use phy-mode only, which is not parsed.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
Currently the init_phy function may overwrite the priv->interface
property, since it calls tsec_get_interface which tries to determine it
dynamically based on default register values in ECNTRL.
Let's do that only if phy-connection-type happens to not be defined in
the device tree.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
The felix driver runs only on NXP LS1028A, which most definitely does
not support the parallel 10G interface, just USXGMII, and that only up
to 2.5Gbps (toned down from 10 Gbps via symbol replication).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
The enetc driver runs only on NXP LS1028A, which most definitely does
not support the parallel 10G interface, just USXGMII, and that only up
to 2.5Gbps (toned down from 10 Gbps via symbol replication).
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
After the discussion here:
https://lore.kernel.org/netdev/20210603143453.if7hgifupx5k433b@pali/
which resulted in this patch:
https://patchwork.kernel.org/project/netdevbpf/patch/20210704134325.24842-1-pali@kernel.org/
and many other discussions before it, notably:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1512016235-15909-1-git-send-email-Bhaskar.Upadhaya@nxp.com/
it became apparent that nobody really knows what "SGMII 2500" is.
Certainly, Freescale/NXP hardware engineers name this protocol
"SGMII 2500" in the reference manuals, but the PCS devices do not
support any "SGMII" specific features when operating at the speed of
2500 Mbps, no in-band autoneg and no speed change via symbol replication
. So that leaves a fixed speed of 2500 Mbps using a coding of 8b/10b
with a SERDES lane frequency of 3.125 GHz. In fact, "SGMII 2500 without
in-band autoneg and at a fixed speed" is indistinguishable from
"2500base-x without in-band autoneg", which is precisely what these NXP
devices support.
So it just appears that "SGMII 2500" is an unclear name with no clear
definition that stuck.
As such, in the Linux kernel, the drivers which use this SERDES protocol
use the 2500base-x phy-mode.
This patch converts U-Boot to use 2500base-x too, or at least, as much
as it can.
Note that I would have really liked to delete PHY_INTERFACE_MODE_SGMII_2500
completely, but the mvpp2 driver seems to even distinguish between SGMII
2500 and 2500base-X. Namely, it enables in-band autoneg for one but not
the other, and forces flow control for one but not the other. This goes
back to the idea that maybe 2500base-X is a fiber protocol and SGMII-2500
is an MII protocol (connects a MAC to a PHY such as Aquantia), but the
two are practically indistinguishable through everything except use case.
NXP devices can support both use cases through an identical configuration,
for example RX flow control can be unconditionally enabled in order to
support rate adaptation performed by an Aquantia PHY. At least I can
find no indication in online documents published by Cisco which would
point towards "SGMII-2500" being an actual standard with an actual
definition, so I cannot say "yes, NXP devices support it".
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
As part of the effort of making U-Boot work with the same device tree as
Linux, there is an issue with the "xfi" phy-mode. To be precise, in
Linux there was a discussion (for those who have time to read:
https://lore.kernel.org/netdev/1576768881-24971-2-git-send-email-madalin.bucur@oss.nxp.com/)
which led to a patch:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c114574ebfdf42f826776f717c8056a00fa94881
TL;DR: "xfi" was standardized in Linux as "10gbase-r".
This patch changes the relevant occurrences in U-Boot to use "10gbase-r"
instead of "xfi" wherever applicable.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
To avoid a warning with W=1 about this function not having a previous
prototype, declare it as static, because it is not used outside of this
translation module.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
NXP Legal insists that the following are not fine:
- Saying "NXP Semiconductors" instead of "NXP", since the company's
registered name is "NXP"
- Putting a "(c)" sign in the copyright string
- Putting a comma in the copyright string
The only accepted copyright string format is "Copyright <year-range> NXP".
This patch changes the copyright headers in the networking files that
were sent by me, or derived from code sent by me.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
|
|
Make sure that the link status returned by phy_startup() is propagated
to the .start() method of struct eth_ops.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Tested-by: Michael Walle <michael@walle.cc>
|
|
It is an unfortunate reality that some PHY settings done by U-Boot
persist even after the PHY is reset and taken over by Linux, and even
more unfortunate that Linux has come to depend on things being set in a
certain way.
For example, on the NXP LS1028A-RDB, the felix switch ports are
connected to a VSC8514 QSGMII PHY. Between the switch port PCS and the
PHY, the U-Boot drivers enable in-band auto-negotiation which makes the
copper-side negotiated speed and duplex be transmitted from the PHY to
the MAC automatically.
The PHY driver portion that does this is in vsc8514_config():
/* Enable Serdes Auto-negotiation */
phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS,
PHY_EXT_PAGE_ACCESS_EXTENDED3);
val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON);
val = val | MIIM_VSC8574_MAC_SERDES_ANEG;
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON, val);
The point is that in-band autoneg should be turned on in both the PHY
and the MAC, or off in both the PHY and the MAC, otherwise the QSGMII
link will be broken.
And because phy_config() is currently called at .port_enable() time, the
result is that ports on which traffic has been sent in U-Boot will have
in-band autoneg enabled, and the rest won't.
It can be argued that the Linux kernel should not assume one way or
another and just reinitialize everything according to what it expects,
and that is completely fair. In fact, I've already started an attempt to
remove this dependency, although admittedly I am making slow progress at
it:
https://patchwork.kernel.org/project/netdevbpf/cover/20210212172341.3489046-1-olteanv@gmail.com/
Nonetheless, the sad reality is that NXP also has, apart from kernel
drivers, some user space networking (DPDK), and for some reason, the
expectation there is that somebody else initializes the PHYs. The kernel
can't do it because the device ownership doesn't belong to the kernel,
so what remains is for the bootloader to do it (especially since other
drivers generally call phy_config() at probe time). This is a really
weak guarantee that might break at any time, but apparently that is
enough for some.
Since initializing the ports and PHYs at probe time does not break
anything, we can just do that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Tested-by: Michael Walle <michael@walle.cc>
|
|
No one is calling this function from outside felix_switch.c.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Tested-by: Michael Walle <michael@walle.cc>
|
