Re: [PATCH 2/2] net: eth-phy: prevent undesired de-assertion of phy-reset on request
On Tue, Mar 1, 2022 at 2:15 PM Tim Harvey wrote: > > When gpio_request_by_name allocates a gpio output it by default will > de-assert the gpio which for phy-reset will take the PHY out of reset. > As this occurs before eth_phy_reset is called to assert the reset > line it can cause undesired affects if reset timings are not properly > met. > > Configure the gpio with GPIOD_IS_OUT_ACTIVE so that reset is kept active > (reset asserted) to avoid this. > > Cc: Sean Anderson > Signed-off-by: Tim Harvey Acked-by: Joe Hershberger
Re: [PATCH 1/2] net: fec: prevent undesired de-assertion of phy-reset on request
On Tue, Mar 1, 2022 at 2:15 PM Tim Harvey wrote: > > When gpio_request_by_name allocates a gpio output it by default will > de-assert the gpio which for phy-reset will take the PHY out of reset. > As this occurs before fec_gpio_reset is called to assert the reset > line it can cause undesired affects if reset timings are not properly > met. > > Configure the gpio with GPIOD_IS_OUT_ACTIVE so that reset is kept active > (reset asserted) to avoid this. > > Cc: Sean Anderson > Signed-off-by: Tim Harvey Acked-by: Joe Hershberger
Re: [PATCH v2 1/2] env: allow environment to be amended from control dtb
On Wed, Apr 21, 2021 at 4:07 AM Rasmus Villemoes wrote: > > It can be useful to use the same U-Boot binary for multiple purposes, > say the normal one, one for developers that allow breaking into the > U-Boot shell, and one for use during bootstrapping which runs a > special-purpose bootcmd. Or one can have several board variants that > can share almost all boot logic, but just needs a few tweaks in the > variables used by the boot script. > > To that end, allow the control dtb to contain a /config/enviroment > node (or whatever one puts in fdt_env_path variable), whose > property/value pairs are used to update the run-time environment after > it has been loaded from its persistent location. > > The indirection via fdt_env_path is for maximum flexibility - for > example, should the user wish (or board logic dictate) that the values > in the DTB should no longer be applied, one simply needs to delete the > fdt_env_path variable; that can even be done automatically by > including a > > fdt_env_path = ""; > > property in the DTB node. > > Reviewed-by: Simon Glass > Signed-off-by: Rasmus Villemoes Cool addition. Acked-by: Joe Hershberger
Re: [PATCH v2 2/2] sandbox: add test of CONFIG_ENV_IMPORT_FDT
On Wed, Apr 21, 2021 at 4:07 AM Rasmus Villemoes wrote: > > Check that a variable defined in /config/environment is found in the > run-time environment, and that clearing fdt_env_path from within that > node works. > > Reviewed-by: Simon Glass > Signed-off-by: Rasmus Villemoes Acked-by: Joe Hershberger
Re: [PATCH] MAINTAINERS: Add maintainer to network subsystem
On Fri, Jan 29, 2021 at 10:18 AM Ramon Fried wrote: > > Add myself as co maintainer to network subsystem > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6d8c467410..dfc8cb7a45 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -893,6 +893,7 @@ F: arch/nds32/ > > NETWORK > M: Joe Hershberger > +M: Ramon Fried > S: Maintained > T: git https://gitlab.denx.de/u-boot/custodians/u-boot-net.git > F: drivers/net/ > -- > 2.29.2 > Acked-by: Joe Hershberger
Re: [PATCH] net: sun8i-emac: Allow all RGMII PHY modes
On Wed, Jan 13, 2021 at 4:43 PM André Przywara wrote: > > On 30/11/2020 17:23, Heinrich Schuchardt wrote: > > Hi Joe, > > > On 11/16/20 10:46 AM, Andre Przywara wrote: > >> So far all GBit users of the sun8i-emac driver were using the "rgmii" > >> PHY mode, even though this turns out to be mostly wrong. It just worked > >> because the PHY driver doesn't do the proper setup (yet). > >> In fact for most boards the "rgmii-id" or "rgmii-txid" PHY modes are the > >> correct ones. > >> > >> To allow the DTs to describe the phy-mode correctly, and to stay > >> compatible with Linux, at least allow those other RGMII modes in the > >> driver. > >> > >> This avoids breakage if mainline DTs will be synced with U-Boot. > >> > >> An almost identical patch (f1239d8aa84d) was merged into the Linux driver > >> and has been backported to stable kernels. > >> > >> Signed-off-by: Andre Przywara > > Are you going to take this through your tree? > Or are you OK with me merging this through u-boot-sunxi? > We depend on this for a DT update, which relies on those new PHY modes. Feel free to take it through your tree. Cheers, -Joe > Cheers, > Andre > > > > > Hello Joe, > > > > could we get this into v2021.01, please? > > > > Acked-by: Heinrich Schuchardt
Re: [PATCH 1/1] env: typo enougth
On Fri, Oct 30, 2020 at 12:11 AM Heinrich Schuchardt wrote: > > %s/enougth/enough/ > > Signed-off-by: Heinrich Schuchardt Acked-by: Joe Hershberger
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On Tue, Aug 18, 2020 at 8:19 AM Adam Ford wrote: > > The ethernet controller can read the MAC from EEPROM and display it, > but if ethaddr is not set, the ethernet is still unavailable. > > This patch checks will automatically set the MAC address if it has > not already been set. > > Signed-off-by: Adam Ford Acked-by: Joe Hershberger
Re: [RFC PATCH] tools: env: Add an option to have an empty default environment
On Wed, Aug 12, 2020 at 8:37 PM Chris Packham wrote:
>
> When building envtools via tools-only_defconfig the builtin defaults
> are based on options in the defconfig. For example:
>
> bootcmd=bootp; setenv bootargs root=/dev/nfs
> nfsroot=${serverip}:${rootpath}
> ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
> bootdelay=2
> baudrate=115200
> stdin=serial,cros-ec-keyb,usbkbd
> stdout=serial,vidconsole
> stderr=serial,vidconsole
> ethaddr=00:00:11:22:33:44
> eth3addr=00:00:11:22:33:45
> eth5addr=00:00:11:22:33:46
> eth6addr=00:00:11:22:33:47
> ipaddr=1.2.3.4
> bootm_size=0x1000
> kernel_addr_r=0x100
> fdt_addr_r=0xc0
> ramdisk_addr_r=0x200
> scriptaddr=0x1000
> pxefile_addr_r=0x2000
>
> These may or may not be sensible for any particular target. Rather than
> trying to have a set of defaults that work for every target add a config
> option to make the default environment completely empty.
>
> Signed-off-by: Chris Packham
Acked-by: Joe Hershberger
Re: [PULL] u-boot-sh/net
On Mon, Jul 27, 2020 at 5:40 AM Marek Vasut wrote: > > More networking DM conversion (this is the last driver). > Any news on Joe ? Sorry, guys, I'm back home in Texas now and have had a lot going on keeping me swamped. I aim to get caught up soon. Any idea how accurate my patchwork queue is? Also, I'd like to get some assistance getting a gitlab validation workflow going. Travis was not helping me be very efficient in testing changes. Thanks, -Joe > The following changes since commit ada61f1ee2a4eaa1b29d699b5ba940483171df8a: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-riscv > (2020-07-24 08:43:08 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git net > > for you to fetch changes up to f23a785cfb451f3fcb457ed1f9141907dce7dd77: > > net: dc2114x: Add DM support (2020-07-25 14:20:56 +0200) > > > Marek Vasut (12): > net: dc2114x: Use PCI_DEVICE() to define PCI device compat list > net: dc2114x: Support all DC2114x > net: dc2114x: Add Kconfig entries > net: dc2114x: Drop update_srom() > net: dc2114x: Use standard I/O accessors > net: dc2114x: Introduce private data > net: dc2114x: Pass private data around > net: dc2114x: Pass PCI BDF into phys_to_bus() > net: dc2114x: Add RX/TX rings into the private data > net: dc2114x: Split RX path > net: dc2114x: Split common parts of non-DM functions out > net: dc2114x: Add DM support > > README | 3 - > configs/integratorap_cm720t_defconfig | 1 + > configs/integratorap_cm920t_defconfig | 1 + > configs/integratorap_cm926ejs_defconfig | 1 + > configs/integratorap_cm946es_defconfig | 1 + > drivers/net/Kconfig | 6 + > drivers/net/dc2114x.c | 611 > ++--- > include/configs/MPC8349EMDS.h | 1 - > include/configs/MPC8349EMDS_SDRAM.h | 1 - > include/configs/MPC8540ADS.h| 1 - > include/configs/MPC8541CDS.h| 1 - > include/configs/MPC8544DS.h | 1 - > include/configs/MPC8548CDS.h| 1 - > include/configs/MPC8555CDS.h| 1 - > include/configs/MPC8560ADS.h| 1 - > include/configs/MPC8568MDS.h| 1 - > include/configs/MPC8569MDS.h| 1 - > include/configs/MPC8572DS.h | 1 - > include/configs/MPC8641HPCN.h | 1 - > include/configs/TQM834x.h | 1 - > include/configs/caddy2.h| 1 - > include/configs/integratorap.h | 1 - > include/configs/sbc8349.h | 1 - > include/configs/sbc8548.h | 1 - > include/configs/sbc8641d.h | 1 - > include/configs/vme8349.h | 1 - > scripts/config_whitelist.txt| 1 - > 27 files changed, 366 insertions(+), 278 deletions(-)
Re: [PATCH 02/13] net: rtl8139: Rework eeprom_delay() macro
On Sun, Apr 12, 2020 at 5:04 PM Marek Vasut wrote: > > The macro assumes ee_addr variable to be present when it's being > used. Rework the macro into a function instead and pass it an > argument specifying the register base address, to make it future > proof for DM conversion. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger Acked-by: Joe Hershberger
Re: [PATCH 01/13] net: rtl8139: Register macro cleanup
On Sun, Apr 12, 2020 at 5:04 PM Marek Vasut wrote: > > Clean up the horrible register definitions in the RTL8139 driver. > This does create a couple of checkpatch errors, but the driver is > full of them anyway, and those will be cleaned up later. > > No functional change. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger Acked-by: Joe Hershberger
Re: [PATCH 01/12] net: ks8851: Replace malloc()+memset() with calloc()
On Wed, Mar 25, 2020 at 1:45 PM Marek Vasut wrote: > > Replace combination of malloc()+memset() with calloc() as the behavior > is exactly the same and the amount of code is reduced. Moreover, remove > printf() in the fail path, as it is useless, and return proper -ENOMEM > return code. > > Signed-off-by: Marek Vasut > Cc: Eugen Hristev > Cc: Joe Hershberger Acked-by: Joe Hershberger
Re: zynq_z_turn_defconfig: broken networking
On Tue, Apr 7, 2020 at 1:34 PM Matwey V. Kornilov wrote: > > вт, 7 апр. 2020 г. в 12:18, Michal Simek : > > > > On 07. 04. 20 11:16, Matwey V. Kornilov wrote: > > > вт, 7 апр. 2020 г. в 12:01, Michal Simek : > > >> > > >> On 07. 04. 20 9:58, Matwey V. Kornilov wrote: > > >>> пн, 6 апр. 2020 г. в 12:41, Michal Simek : > > >>>> > > >>>> Hi, > > >>>> > > >>>> On 06. 04. 20 10:14, Matwey V. Kornilov wrote: > > >>>>> 06.04.2020 11:12, Matwey V. Kornilov пишет: > > >>>>>> Hello, > > >>>>>> > > >>>>>> I am running u-boot 2020.04-rc4-00100-g74bf17db39 with > > >>>>>> zynq_z_turn_defconfig configuration on MYIR Z-Turn board. > > >>>>>> And I see the following when I am trying to run `dhcp' command. > > >>>>>> > > >>>>>> > > >>>>>> ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id > > >>>>>> mdio_register: non unique device name 'eth0' > > >>>>>> ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id > > >>>>>> mdio_register: non unique device name 'eth0' > > >>>>>> ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id > > >>>>>> mdio_register: non unique device name 'eth0' > > >>>>>> ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id > > >>>>>> mdio_register: non unique device name 'eth0' > > >>>>>> No ethernet found. > > >>>>>> ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id > > >>>>>> mdio_register: non unique device name 'eth0' > > >>>>>> > > >>>>> > > >>>>> Full boot log is the following: > > >>>>> > > >>>>> > > >>>>> U-Boot SPL 2020.04-rc4-00100-g74bf17db39 (Apr 06 2020 - 11:00:45 > > >>>>> +0300) > > >>>>> mmc boot > > >>>>> Trying to boot from MMC1 > > >>>>> spl_load_image_fat_os: error reading image system.dtb, err - -2 > > >>>>> > > >>>>> > > >>>>> U-Boot 2020.04-rc4-00100-g74bf17db39 (Apr 06 2020 - 11:00:45 +0300) > > >>>>> > > >>>>> CPU: Zynq 7z010 > > >>>>> Silicon: v3.1 > > >>>>> Model: Zynq Z-Turn MYIR Board > > >>>>> DRAM: ECC disabled 1 GiB > > >>>>> MMC: mmc@e010: 0 > > >>>>> In:serial@e0001000 > > >>>>> Out: serial@e0001000 > > >>>>> Err: serial@e0001000 > > >>>>> Net: ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id > > >>>>> Could not get PHY for eth0: addr 0 > > >>>>> No ethernet found. > > >>>>> > > >>>>> Hit any key to stop autoboot: 0 > > >>>>> > > >>>> > > >>>> u-boot is not able to find out your phy. Address is setup 0 which means > > >>>> u-boot should do it autodetection. I don't have this board here to tell > > >>>> you what can be wrong. > > >>>> > > >>>> Alex, Anton: Can you please comment it? > > >>>> > > >>> > > >>> Is there a chance that something is wrong with ps7_init_gpl.c ? > > >>> The Ethernet PHY doesn't work in Linux too with the similar error > > >>> message. > > >> > > >> Did you validate any golden images that phy is fine? > > > > > > Yes, I did. There was microsd card supplied with the board (it has > > > U-Boot 2013.10-svn7 and 3.15.0-xilinx kernel). The Ethernet is working > > > with this image. > > > > > >> > > >> Anyway as I said I don't have this board here that's why guys who has it > > >> should debug it or patches welcome. > > >> Or 3rd option is if none wants to keep it alive I will remove support > > >> for it. > > > > > > Well, unfortunately, I have little knowledge how to debug this, but if > > > you have an ideas what could I check, please ask. > > > > This board is in mainline for a while. That's why you can go back to > > commit which introduced this board and try it. Then you can bisect it > > and see which commit breaks it. > > Thanks. I've found where Ethernet was broken: > > 1f60789602e0d5f5f9a8b507f25737c65b5d8daa is the first bad commit > commit 1f60789602e0d5f5f9a8b507f25737c65b5d8daa > Author: Priyanka Jain > Date: Tue Nov 5 04:05:11 2019 + > > net/phy: Fix phy_connect() for phy addr 0 > > Fix 'mask' calculation in phy_connect() for phy addr '0'. > 'mask' is getting set to '0x' for phy addr '0' > in phy_connect() whereas expected value is '0'. > > Signed-off-by: Priyanka Jain > Reported-by: tetsu-aoki via github > Acked-by: Joe Hershberger > So presumably that means the phy addr should be set to -1 instead of 0 for autodetect, right? I believe this was seen on at least one other board [1]. [1] - https://www.mail-archive.com/u-boot@lists.denx.de/msg351386.html Cheers, -Joe > > > > Thanks, > > Michal > > > > -- > > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 > > w: www.monstr.eu p: +42-0-721842854 > > Maintainer of Linux kernel - Xilinx Microblaze > > Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs > > U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs > > > > > -- > With best regards, > Matwey V. Kornilov
Re: [PATCH] net: phy: micrel: ksz8061 implement errata 80000688A fix
On Thu, Mar 26, 2020 at 6:25 AM Bryan O'Donoghue wrote:
>
> Linux commit 232ba3a51cc2 ('net: phy: Micrel KSZ8061: link failure after
> cable connect') implements a fix for the above errata.
>
> This patch replicates that errata fix in an ksz8061 specific init routine.
>
> Signed-off-by: Bryan O'Donoghue
Acked-by: Joe Hershberger
Re: [PATCH] net: macb: Fix incorrect write function name when MACB_ZYNQ is enabled.
On Thu, Mar 26, 2020 at 9:01 AM Michal Simek wrote:
>
> When MACB_ZYNQ is enabled there is compilation warnings
> drivers/net/macb.c: In function ‘_macb_init’:
> drivers/net/macb.h:675:33: error: ‘MACB_DMACFG’ undeclared (first use in this
> function);
> did you mean ‘MACB_MCF’?
> writel((value), (port)->regs + MACB_##reg)
> ^
>
> It has been caused by changing macros name by commit below.
>
> Fixes: 6c636514d499 ("net: macb: sync header definitions as taken from Linux")
> Signed-off-by: Michal Simek
Acked-by: Joe Hershberger
Re: [PATCH] [RFC] net: smc911x: Drop the standalone EEPROM example
Hi Tom, On Tue, Mar 17, 2020 at 7:59 PM Tom Rini wrote: > > On Tue, Mar 17, 2020 at 07:54:51PM -0500, Joe Hershberger wrote: > > On Tue, Mar 17, 2020 at 1:55 PM Tom Rini wrote: > > > > > > On Tue, Mar 17, 2020 at 07:53:58PM +0100, Marek Vasut wrote: > > > > On 3/17/20 7:44 PM, Tom Rini wrote: > > > > > On Tue, Mar 17, 2020 at 07:43:11PM +0100, Marek Vasut wrote: > > > > >> On 3/17/20 7:42 PM, Tom Rini wrote: > > > > >>> On Tue, Mar 17, 2020 at 07:39:49PM +0100, Marek Vasut wrote: > > > > >>>> On 3/17/20 7:30 PM, Tom Rini wrote: > > > > >>>>> On Tue, Mar 17, 2020 at 07:23:07PM +0100, Marek Vasut wrote: > > > > >>>>>> On 3/17/20 7:10 PM, Masahiro Yamada wrote: > > > > >>>>>>> On Sun, Mar 15, 2020 at 8:19 AM Marek Vasut > > > > >>>>>>> wrote: > > > > >>>>>>>> > > > > >>>>>>>> Drop the example, for two reasons. First, it is tapping > > > > >>>>>>>> directly into > > > > >>>>>>>> the IO accessors of the SMC911x, while it should instead go > > > > >>>>>>>> through > > > > >>>>>>>> the net device API. Second, this makes conversion of the > > > > >>>>>>>> SMC911x driver > > > > >>>>>>>> to DM real hard. > > > > >>>>>>>> > > > > >>>>>>>> Signed-off-by: Marek Vasut > > > > >>>>>>>> Cc: Joe Hershberger > > > > >>>>>>>> Cc: Tom Rini > > > > >>>>>>>> --- > > > > >>>>>>>> examples/standalone/Makefile | 1 - > > > > >>>>>>>> examples/standalone/smc911x_eeprom.c | 379 > > > > >>>>>>>> --- > > > > >>>>>>>> 2 files changed, 380 deletions(-) > > > > >>>>>>>> delete mode 100644 examples/standalone/smc911x_eeprom.c > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> Yeah, I was disturbed by this example code. > > > > >>>>>>> > > > > >>>>>>> I agree we should drop it. > > > > >>>>>>> > > > > >>>>>>> Reviewed-by: Masahiro Yamada > > > > >>>>>> > > > > >>>>>> Well I dunno. Can this be rewritten on top of DM somehow ? Do we > > > > >>>>>> even > > > > >>>>>> have U-Boot application API to access DM EEPROM ? > > > > >>>>> > > > > >>>>> We should just drop it I think. The biggest surface we have > > > > >>>>> today for > > > > >>>>> external application is EFI application now, not U-Boot specific > > > > >>>>> API. > > > > >>>>> We can't drop the API but we don't expand it without very good > > > > >>>>> reason. > > > > >>>> > > > > >>>> But this drops the ability to access the SMC911x EEPROM too. > > > > >>>> So maybe we need some DM EEPROM implementation in the SMC911x > > > > >>>> driver ? > > > > >>>> Does anyone have SMC911x with an external EEPROM ? > > > > >>> > > > > >>> All this does is drop an example. I don't see anything removing API > > > > >>> code itself. > > > > >> > > > > >> Where did I say anything about API code ? > > > > > > > > > > Nowhere, which is my point. You're just dropping an example, not the > > > > > ability to do $X. > > > > > > > > If $X is ability to access the EEPROM, then I am dropping $X here. > > > > > > No, you're dropping an example of doing $X. > > > > Correct. But the move to DM in the driver will drop the functions this > > example was using, no? > > If it was using something that's not in <_exports.h> I don't see that as > a problem. A standalone app could do whatever it likes with the > hardware and needs to restore the hardware before passing control back > to U-Boot (if it's doing that). My understanding (correct me if I'm wrong) is that the SCM911x driver in question used to expose its eeprom through the external API, but not as though there was a special API directly implemented in that driver. I think the behavior change that Marek was concerned about was that this particular device would not be accessible via the external eeprom api any longer. -Joe
Re: [PATCH 02/14] drivers: net: ldpaa: add support for probing based on the DTS
On Thu, Mar 12, 2020 at 11:26 AM Ioana Ciornei wrote:
>
> When CONFIG_DM_ETH is enabled DPAA2 network interfaces will now probe
> based on DTS nodes with the "fsl,qoriq-mc-dpmac" compatible.
> In this case, transform the ldpaa_eth driver into a UCLASS_ETH driver
> and reuse the _open()/_tx()/_stop() functions already inplemented.
>
> For the moment, the ldpaa_eth driver will support both configurations:
> with or without CONFIG_DM_ETH enabled. Any 'struct eth_device' occurrence
> now has a matching 'struct udevice' made mutually exclusive based on the
> state of CONFIG_DM_ETH.
>
> Signed-off-by: Florin Laurentiu Chiculita
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/ldpaa_eth/ldpaa_eth.c | 230 +-
> drivers/net/ldpaa_eth/ldpaa_eth.h | 6 +
> 2 files changed, 204 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
> b/drivers/net/ldpaa_eth/ldpaa_eth.c
> index a3b9c152b256..bbfe479ed1c9 100644
> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -19,6 +20,7 @@
> #include "ldpaa_eth.h"
>
> #ifdef CONFIG_PHYLIB
> +#ifndef CONFIG_DM_ETH
Please use positive logic here and throughout. Add the DM code here
before the non-DM code.
> static int init_phy(struct eth_device *dev)
> {
> struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)dev->priv;
> @@ -62,6 +64,19 @@ static int init_phy(struct eth_device *dev)
>
> return ret;
> }
> +#else
> +static void init_phy(struct udevice *dev)
> +{
> + struct ldpaa_eth_priv *priv = dev_get_priv(dev);
> +
> + priv->phy = dm_eth_phy_connect(dev);
> +
> + if (!priv->phy)
> + return;
> +
> + phy_config(priv->phy);
> +}
> +#endif
> #endif
>
> #ifdef DEBUG
> @@ -128,9 +143,15 @@ static void ldpaa_eth_get_dpni_counter(void)
> }
> }
>
> +#ifdef CONFIG_DM_ETH
> +static void ldpaa_eth_get_dpmac_counter(struct udevice *dev)
> +{
> + struct ldpaa_eth_priv *priv = dev_get_priv(dev);
> +#else
> static void ldpaa_eth_get_dpmac_counter(struct eth_device *net_dev)
> {
> struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)net_dev->priv;
> +#endif
> int err = 0;
> u64 value;
>
> @@ -263,9 +284,16 @@ error:
> return;
> }
>
> +#ifdef CONFIG_DM_ETH
> +static int ldpaa_eth_pull_dequeue_rx(struct udevice *dev,
> +int flags, uchar **packetp)
> +{
> + struct ldpaa_eth_priv *priv = dev_get_priv(dev);
> +#else
> static int ldpaa_eth_pull_dequeue_rx(struct eth_device *dev)
> {
> struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)dev->priv;
> +#endif
> const struct ldpaa_dq *dq;
> const struct dpaa_fd *fd;
> int i = 5, err = 0, status;
> @@ -322,9 +350,15 @@ static int ldpaa_eth_pull_dequeue_rx(struct eth_device
> *dev)
> return err;
> }
>
> +#ifdef CONFIG_DM_ETH
> +static int ldpaa_eth_tx(struct udevice *dev, void *buf, int len)
> +{
> + struct ldpaa_eth_priv *priv = dev_get_priv(dev);
> +#else
> static int ldpaa_eth_tx(struct eth_device *net_dev, void *buf, int len)
> {
> struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)net_dev->priv;
> +#endif
> struct dpaa_fd fd;
> u64 buffer_start;
> int data_offset, err;
> @@ -400,15 +434,32 @@ error:
> return err;
> }
>
> +static struct phy_device *ldpaa_get_phydev(struct ldpaa_eth_priv *priv)
> +{
> +#ifdef CONFIG_DM_ETH
> + return priv->phy;
> +#else
> +#ifdef CONFIG_PHYLIB
> + struct phy_device *phydev = NULL;
> + int phy_num;
> +
> + /* start the phy devices one by one and update the dpmac state */
> + for (phy_num = 0; phy_num < WRIOP_MAX_PHY_NUM; phy_num++) {
> + phydev = wriop_get_phy_dev(priv->dpmac_id, phy_num);
> + if (phydev)
> + return phydev;
> + }
> + return NULL;
> +#endif
> +#endif
> +}
> +
> static int ldpaa_get_dpmac_state(struct ldpaa_eth_priv *priv,
> struct dpmac_link_state *state)
> {
> phy_interface_t enet_if;
> - int phys_detected;
> -#ifdef CONFIG_PHYLIB
> struct phy_device *phydev = NULL;
> - int err, phy_num;
> -#endif
> + int err;
>
> /* let's start off with maximum capabilities */
> enet_if = wriop_get_enet_if(priv->dpmac_id);
> @@ -420,39 +471,28 @@ static int ldpaa_get_dpmac_state(struct ldpaa_eth_priv
> *priv,
> state->rate = SPEED_1000;
> break;
> }
> - state->up = 1;
>
> - phys_detected = 0;
> -#ifdef CONFIG_PHYLIB
> + state->up = 1;
> state->options |= DPMAC_LINK_OPT_AUTONEG;
> + phydev = ldpaa_get_phydev(priv);
>
> - /* start the phy devices one by one and update the dpmac state */
> - for (phy_num = 0; phy_num <
Re: [PATCH 01/14] drivers: net: add Layerscape mEMAC MDIO driver
On Thu, Mar 12, 2020 at 11:24 AM Ioana Ciornei wrote:
>
> Add a driver for the MDIO interface integrated in the mEMAC (Multi-rate
> Ethernet Media Access Controller) and the Fman 10G Ethernet MACs.
>
> Signed-off-by: Ioana Ciornei
> ---
> drivers/net/Kconfig | 7 ++
> drivers/net/Makefile | 1 +
> drivers/net/fsl_ls_mdio.c | 158 ++
> 3 files changed, 166 insertions(+)
> create mode 100644 drivers/net/fsl_ls_mdio.c
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 4d1013c98466..bc518f218da6 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -640,4 +640,11 @@ config MVMDIO
>
> This driver is used by the MVPP2 and MVNETA drivers.
>
> +config FSL_LS_MDIO
> + bool "NXP Layerscape MDIO interface support"
> + depends on DM_MDIO
> + help
> + This driver supports the MDIO bus found on the Fman 10G Ethernet
> MACs and
> + on the mEMAC (which supports both Clauses 22 and 45).
> +
> endif # NETDEVICES
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 6e0a68834d97..6d9b8772b1a5 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -83,3 +83,4 @@ obj-y += mscc_eswitch/
> obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
> obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
> obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o
> +obj-$(CONFIG_FSL_LS_MDIO) += fsl_ls_mdio.o
> diff --git a/drivers/net/fsl_ls_mdio.c b/drivers/net/fsl_ls_mdio.c
> new file mode 100644
> index ..845c0ac1ffd8
> --- /dev/null
> +++ b/drivers/net/fsl_ls_mdio.c
> @@ -0,0 +1,158 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN
Is there a reason we have a special separate endian flag for this NIC
instead of using a platform config?
> +#define memac_out_32(a, v) out_le32(a, v)
> +#define memac_clrbits_32(a, v) clrbits_le32(a, v)
> +#define memac_setbits_32(a, v) setbits_le32(a, v)
> +#else
> +#define memac_out_32(a, v) out_be32(a, v)
> +#define memac_clrbits_32(a, v) clrbits_be32(a, v)
> +#define memac_setbits_32(a, v) setbits_be32(a, v)
> +#endif
> +
> +static u32 memac_in_32(u32 *reg)
> +{
> +#ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN
> + return in_le32(reg);
> +#else
> + return in_be32(reg);
> +#endif
> +}
> +
> +struct fsl_ls_mdio_priv {
> + void *regs_base;
> +};
> +
> +static int dm_fsl_ls_mdio_read(struct udevice *dev, int addr,
> + int devad, int reg)
> +{
> + struct fsl_ls_mdio_priv *priv = dev_get_priv(dev);
> + struct memac_mdio_controller *regs;
> + u32 mdio_ctl;
> + u32 c45 = 1;
> +
> + regs = (struct memac_mdio_controller *)(priv->regs_base);
> + if (devad == MDIO_DEVAD_NONE) {
> + c45 = 0; /* clause 22 */
> + devad = reg & 0x1f;
> + memac_clrbits_32(>mdio_stat, MDIO_STAT_ENC);
> + } else {
> + memac_setbits_32(>mdio_stat, MDIO_STAT_ENC);
> + }
> +
> + /* Wait till the bus is free */
> + while ((memac_in_32(>mdio_stat)) & MDIO_STAT_BSY)
> + ;
> +
> + /* Set the Port and Device Addrs */
> + mdio_ctl = MDIO_CTL_PORT_ADDR(addr) | MDIO_CTL_DEV_ADDR(devad);
> + memac_out_32(>mdio_ctl, mdio_ctl);
> +
> + /* Set the register address */
> + if (c45)
> + memac_out_32(>mdio_addr, reg & 0x);
> +
> + /* Wait till the bus is free */
> + while ((memac_in_32(>mdio_stat)) & MDIO_STAT_BSY)
> + ;
> +
> + /* Initiate the read */
> + mdio_ctl |= MDIO_CTL_READ;
> + memac_out_32(>mdio_ctl, mdio_ctl);
> +
> + /* Wait till the MDIO write is complete */
> + while ((memac_in_32(>mdio_data)) & MDIO_DATA_BSY)
> + ;
> +
> + /* Return all Fs if nothing was there */
> + if (memac_in_32(>mdio_stat) & MDIO_STAT_RD_ER)
> + return 0x;
> +
> + return memac_in_32(>mdio_data) & 0x;
> + return 0;
> +}
> +
> +static int dm_fsl_ls_mdio_write(struct udevice *dev, int addr, int devad,
> + int reg, u16 val)
> +{
> + struct fsl_ls_mdio_priv *priv = dev_get_priv(dev);
> + struct memac_mdio_controller *regs;
> + u32 mdio_ctl;
> + u32 c45 = 1;
> +
> + regs = (struct memac_mdio_controller *)(priv->regs_base);
> + if (devad == MDIO_DEVAD_NONE) {
> + c45 = 0; /* clause 22 */
> + devad = reg & 0x1f;
> + memac_clrbits_32(>mdio_stat, MDIO_STAT_ENC);
> + } else {
> + memac_setbits_32(>mdio_stat, MDIO_STAT_ENC);
> + }
> +
> + /* Wait till the bus is free */
> + while ((memac_in_32(>mdio_stat)) & MDIO_STAT_BSY)
> + ;
> +
> + /* Set the port and dev addr */
> +
Re: [PATCH] [RFC] net: smc911x: Drop the standalone EEPROM example
On Sat, Mar 14, 2020 at 6:19 PM Marek Vasut wrote: > > Drop the example, for two reasons. First, it is tapping directly into > the IO accessors of the SMC911x, while it should instead go through > the net device API. Second, this makes conversion of the SMC911x driver > to DM real hard. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Tom Rini Acked-by: Joe Hershberger
Re: [PATCH 12/12] net: smc911x: Add DM support
On Sun, Mar 15, 2020 at 12:01 PM Marek Vasut wrote:
>
> Add support for U-Boot DM and DT probing. Furthermore, build the
> SMC911x standalone EEPROM example only for the non-DM case, as it
> is not converted yet.
>
> Signed-off-by: Marek Vasut
> Cc: Joe Hershberger
> Cc: Masahiro Yamada
> ---
> board/renesas/blanche/blanche.c | 2 +
> drivers/net/smc911x.c | 114
> examples/standalone/Makefile| 5 +-
> 3 files changed, 120 insertions(+), 1 deletion(-)
>
> diff --git a/board/renesas/blanche/blanche.c b/board/renesas/blanche/blanche.c
> index 7232370d6f..eec1dde106 100644
> --- a/board/renesas/blanche/blanche.c
> +++ b/board/renesas/blanche/blanche.c
> @@ -313,6 +313,7 @@ int board_init(void)
> }
>
> /* Added for BLANCHE(R-CarV2H board) */
> +#ifndef CONFIG_DM_ETH
> int board_eth_init(bd_t *bis)
> {
> int rc = 0;
> @@ -337,6 +338,7 @@ int board_eth_init(bd_t *bis)
>
> return rc;
> }
> +#endif
>
> int dram_init(void)
> {
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index 71c7a2e632..8abc5e97ac 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -21,7 +21,9 @@ struct chip_id {
> };
>
> struct smc911x_priv {
> +#ifndef CONFIG_DM_ETH
> struct eth_device dev;
> +#endif
> phys_addr_t iobase;
> const struct chip_id*chipid;
> unsigned char enetaddr[6];
> @@ -371,6 +373,8 @@ static int smc911x_recv_common(struct smc911x_priv *priv,
> u32 *data)
> return pktlen;
> }
>
> +#ifndef CONFIG_DM_ETH
Please use positive logic here.
> +
> #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
> /* wrapper for smc911x_eth_phy_read */
> static int smc911x_miiphy_read(struct mii_dev *bus, int phy, int devad,
> @@ -502,3 +506,113 @@ int smc911x_initialize(u8 dev_num, int base_addr)
>
> return 1;
> }
> +
> +#else /* ifdef CONFIG_DM_ETH */
> +
> +static int smc911x_start(struct udevice *dev)
> +{
> + struct eth_pdata *plat = dev_get_platdata(dev);
> + struct smc911x_priv *priv = dev_get_priv(dev);
> +
> + memcpy(priv->enetaddr, plat->enetaddr, sizeof(plat->enetaddr));
> +
> + return smc911x_init_common(priv);
> +}
> +
> +static void smc911x_stop(struct udevice *dev)
> +{
> + struct smc911x_priv *priv = dev_get_priv(dev);
> +
> + smc911x_halt_common(priv);
> +}
> +
> +static int smc911x_send(struct udevice *dev, void *packet, int length)
> +{
> + struct smc911x_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + ret = smc911x_send_common(priv, packet, length);
> +
> + return ret ? 0 : -ETIMEDOUT;
> +}
> +
> +static int smc911x_recv(struct udevice *dev, int flags, uchar **packetp)
> +{
> + struct smc911x_priv *priv = dev_get_priv(dev);
> + u32 *data = (u32 *)net_rx_packets[0];
> + int ret;
> +
> + ret = smc911x_recv_common(priv, data);
> + if (ret)
> + *packetp = (void *)data;
> +
> + return ret ? ret : -EAGAIN;
> +}
> +
> +static int smc911x_bind(struct udevice *dev)
> +{
> + return device_set_name(dev, dev->name);
> +}
> +
> +static int smc911x_probe(struct udevice *dev)
> +{
> + struct smc911x_priv *priv = dev_get_priv(dev);
> + unsigned long addrh, addrl;
> + int ret;
> +
> + /* Try to detect chip. Will fail if not present. */
> + ret = smc911x_detect_chip(priv);
> + if (ret)
> + return ret;
> +
> + addrh = smc911x_get_mac_csr(priv, ADDRH);
> + addrl = smc911x_get_mac_csr(priv, ADDRL);
> + if (!(addrl == 0x && addrh == 0x)) {
> + /* address is obtained from optional eeprom */
> + priv->enetaddr[0] = addrl;
> + priv->enetaddr[1] = addrl >> 8;
> + priv->enetaddr[2] = addrl >> 16;
> + priv->enetaddr[3] = addrl >> 24;
> + priv->enetaddr[4] = addrh;
> + priv->enetaddr[5] = addrh >> 8;
> + }
Can you make a common function for sharing the MAC address parsing?
> +
> + return 0;
> +}
> +
> +static int smc911x_ofdata_to_platdata(struct udevice *dev)
> +{
> + struct smc911x_priv *priv = dev_get_priv(dev);
> + struct eth_pdata *pdata = dev_get_platdata(dev);
> +
> + pdata->iobase = devfdt_get_addr(dev);
> + priv->iobase = pdata->iobase;
> +
> + return 0;
> +}
> +
> +static const struct e
Re: [PATCH 11/12] net: smc911x: Split non-DM specific bits from common code
On Sun, Mar 15, 2020 at 12:01 PM Marek Vasut wrote: > > Split network handling functions into non-DM specific parts and > common code in preparation for conversion to DM. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Masahiro Yamada Acked-by: Joe Hershberger
Re: [PATCH 10/12] net: smc911x: Clean up the status handling in smc911x_recv()
On Sun, Mar 15, 2020 at 12:01 PM Marek Vasut wrote:
>
> Invest the status handling logic in smc911x_recv(), to make the
> function easier to read, no functional change.
Invest -> Invert
> Signed-off-by: Marek Vasut
> Cc: Joe Hershberger
> Cc: Masahiro Yamada
> ---
> drivers/net/smc911x.c | 31 +--
> 1 file changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index fc874e8d2a..a6da586448 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -352,23 +352,26 @@ static int smc911x_recv(struct eth_device *dev)
> u32 pktlen, tmplen;
> u32 status;
>
> - if ((smc911x_reg_read(priv, RX_FIFO_INF) & RX_FIFO_INF_RXSUSED) >>
> 16) {
> - status = smc911x_reg_read(priv, RX_STATUS_FIFO);
> - pktlen = (status & RX_STS_PKT_LEN) >> 16;
> + status = smc911x_reg_read(priv, RX_FIFO_INF);
> + status = (status & RX_FIFO_INF_RXSUSED) >> 16;
> + if (!status)
> + return 0;
>
> - smc911x_reg_write(priv, RX_CFG, 0);
> + status = smc911x_reg_read(priv, RX_STATUS_FIFO);
> + pktlen = (status & RX_STS_PKT_LEN) >> 16;
>
> - tmplen = (pktlen + 3) / 4;
> - while (tmplen--)
> - *data++ = smc911x_reg_read(priv, RX_DATA_FIFO);
> + smc911x_reg_write(priv, RX_CFG, 0);
>
> - if (status & RX_STS_ES)
> - printf(DRIVERNAME
> - ": dropped bad packet. Status: 0x%08x\n",
> - status);
> - else
> - net_process_received_packet(net_rx_packets[0],
> pktlen);
> - }
> + tmplen = (pktlen + 3) / 4;
> + while (tmplen--)
> + *data++ = smc911x_reg_read(priv, RX_DATA_FIFO);
> +
> + if (status & RX_STS_ES)
> + printf(DRIVERNAME
> + ": dropped bad packet. Status: 0x%08x\n",
> + status);
> + else
> + net_process_received_packet(net_rx_packets[0], pktlen);
>
> return 0;
> }
> --
> 2.25.0
>
Re: [PATCH 09/12] net: smc911x: Pass around driver private data
On Sun, Mar 15, 2020 at 12:01 PM Marek Vasut wrote: > > Introduce a private data structure for this driver with embedded > struct eth_device and pass it around. This prepares the driver to > work with both DM and non-DM systems. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Masahiro Yamada Acked-by: Joe Hershberger
Re: [PATCH 08/12] net: smc911x: Convert IO accessors to {read, write}{w, l}()
On Sun, Mar 15, 2020 at 12:00 PM Marek Vasut wrote: > > Convert the IO accessors to standard ones instead of using volatile > void pointers, as those do not cover all the bus access details. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Masahiro Yamada Acked-by: Joe Hershberger
Re: [PATCH 07/12] net: smc911x: Drop weak alias from 32bit accessors
On Sun, Mar 15, 2020 at 12:00 PM Marek Vasut wrote: > > These accessors are not overriden by any board, and even if they were, > this is something which should be handled via DM now, so remove the > weak alias option. Moreover, drop the inline keyword, as the compiler > can decide better. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Masahiro Yamada Acked-by: Joe Hershberger
Re: [PATCH 06/12] net: smc911x: Inline all functions from header file
On Sun, Mar 15, 2020 at 12:00 PM Marek Vasut wrote: > > Inline all the functions from the header file, as they are not used > outside of the driver or the standalone EEPROM example. > > Note that this does introduce considerable amount of duplication in > the standalone EEPROM example, however that one has to be rewritten > anyway, roughly such that the SMC911x driver would expose DM EEPROM > interface and the standalone example would use that. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Masahiro Yamada Acked-by: Joe Hershberger
Re: [PATCH 05/12] net: smc911x: Fix potential memleak() in init fail path
On Sun, Mar 15, 2020 at 11:59 AM Marek Vasut wrote: > > Fix memleak in the init fail path, where if allocation or registration > of MDIO bus fails, then ethernet interface is not unregistered and the > private data are not freed, yet the probe function reports a failure. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Masahiro Yamada Acked-by: Joe Hershberger
Re: [PATCH 02/12] net: smc911x: Replace malloc()+memset() with calloc()
On Sun, Mar 15, 2020 at 12:00 PM Marek Vasut wrote: > > Replace combination of malloc()+memset() with calloc() as the behavior > is exactly the same and the amount of code is reduced. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Masahiro Yamada Acked-by: Joe Hershberger
Re: [PATCH 01/12] net: smc911x: Remove pkt_data_{push,pull}
On Sun, Mar 15, 2020 at 11:59 AM Marek Vasut wrote: > > These functions are never used and are likely a pre-DM remnant > from times long past, just remove them. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Masahiro Yamada Acked-by: Joe Hershberger
Re: [PATCH] net: eth-uclass: Do not return error when no MAC is found
On Tue, Mar 10, 2020 at 1:34 PM Fabio Estevam wrote:
>
> Hi Joe,
>
> On Tue, Mar 10, 2020 at 2:45 PM Joe Hershberger
> wrote:
>
> > I tried to apply this but it breaks the unit tests. I guess you didn't
> > try "ut dm" in sandbox?
> >
> > https://travis-ci.org/jhershbe/u-boot/builds/660395782
> >
> > Please test those and update the tests to pass with your change.
>
> Ok, I will revisit this patch after 2020.04.
>
> I think we should probably let net_random_ethaddr() run unconditionally:
That may be a better solution... with the warning of course.
Cheers,
-Joe
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -547,15 +547,9 @@ static int eth_post_probe(struct udevice *dev)
>dev->name);
> } else if (is_zero_ethaddr(pdata->enetaddr) ||
>!is_valid_ethaddr(pdata->enetaddr)) {
> -#ifdef CONFIG_NET_RANDOM_ETHADDR
> net_random_ethaddr(pdata->enetaddr);
> printf("\nWarning: %s (eth%d) using random MAC address -
> %pM\n",
>dev->name, dev->seq, pdata->enetaddr);
> -#else
> - printf("\nError: %s address not set.\n",
> - dev->name);
> - return -EINVAL;
> -#endif
> }
>
> eth_write_hwaddr(dev);
>
> Thanks
Re: [PATCH v2 00/12] phy: atheros: dt bindings and cleanup
Hi Michael,
On Tue, Jan 7, 2020 at 5:07 AM Michael Walle wrote:
>
> Hi all,
>
> Am 2019-12-05 23:57, schrieb Michael Walle:
> > [RESEND because I've forgot to add the mailinglist. Sorry!]
> >
> > This patch series superseeds the following two:
> > From Vladimir Oltean
> > https://patchwork.ozlabs.org/cover/1031360/
> > From me:
> > https://patchwork.ozlabs.org/cover/1184507/
> >
> > Although the first is marked as accepted into u-boot-net I guess it was
> > removed due to broken boards ("DT as ABI", RGMII delay was fixed and
> > thus
> > breaks the board).
> >
> > After disussing with Vladimir, I've integrated his patches with this
> > series. Also the first one
> > Address packet drops at low traffic rate due to SmartEEE feature
> > was dropped because it will likely be fixed by making u-boot support
> > the
> > eee-broken-X device tree properties. Apart from that, only the subject
> > was
> > changed and a note about possible board breakage was added the patch
> > which
> > changes the delay behaviour.
> >
> > For all of those, who will test this patchset, the device tree binding
> > needs the phydev->node property, which needs to be set in every network
> > driver. If the device tree binding is not working for you have a look
> > at
> > the
> > ar803x_of_init: found PHY node: phy@0
> > output. In the case above "phy@0" is the phy node in the device tree.
> > If
> > instead the node of your network device is displayed, you have to set
> > the phydev->node property in your network device driver.
> >
> > For the fsl_enetc driver this patchset will add it:
> > https://patchwork.ozlabs.org/cover/1188043/
>
> ping :)
>
> would be cool to have that merged in the current window.
I tried to merge in the current window, but it broke some boards.
https://travis-ci.org/jhershbe/u-boot/builds/660395885
Please have a look and send a new version that passes those builds.
Thanks,
-Joe
> -michael
>
>
>
> >
> > changes since v1:
> > - pull all Vladimirs Oltan's patches and rebase mine onto them
> > - fix the CLK_25M settings for the AR8035
> > - add two new patches "fix AR8021 PHY ID mask" and "use defines for
> > PHY
> >IDs"
> > - use the new kernel device tree binding for the AR803x PHYs:
> >https://patchwork.ozlabs.org/patch/1188293/
> > - add debugging output
> >
> > Michael Walle (7):
> > phy: atheros: fix AR8021 PHY ID mask
> > phy: atheros: use defines for PHY IDs
> > phy: atheros: introduce debug read and write functions
> > phy: atheros: move delay config to common function
> > phy: atheros: add device tree bindings and config
> > phy: atheros: ar8035: remove static clock config
> > phy: atheros: consolidate {ar8031|ar8035}_config()
> >
> > Vladimir Oltean (5):
> > phy: atheros: Make RGMII Tx delays actually configurable for AR8035
> > phy: atheros: Use common functions for RGMII internal delays
> > phy: atheros: Clarify the configuration of the CLK_25M output pin
> > phy: atheros: Explicitly disable RGMII delays
> > phy: atheros: Clarify the intention of ar8021_config
> >
> > doc/device-tree-bindings/net/phy/atheros.txt | 35 ++
> > drivers/net/phy/atheros.c| 349 ---
> > include/dt-bindings/net/qca-ar803x.h | 13 +
> > 3 files changed, 344 insertions(+), 53 deletions(-)
> > create mode 100644 doc/device-tree-bindings/net/phy/atheros.txt
> > create mode 100644 include/dt-bindings/net/qca-ar803x.h
Re: [PATCH] net: eth-uclass: Do not return error when no MAC is found
Hi Fabio, On Thu, Jan 9, 2020 at 12:29 PM Fabio Estevam wrote: > > On some i.MX8QXP MEK boards with no MAC address stored, the following > hang is seen: > > Error: ethernet@5b04 address not set. > > (Board hangs) > > One way to avoid this issue is to select CONFIG_NET_RANDOM_ETHADDR, so > that a random MAC is provided and boot proceeds, but the lack of MAC > should not hang the entire system. > > Fix the hang by removing the propagation of error when no MAC is found. > > In this case there are already messages indicating that something > is not correct: > > Error: ethernet@5b04 address not set. > > Error: ethernet@5b04 address 00:00:00:00:00:00 illegal value > eth0: ethernet@5b04 > Error: ethernet@5b04 address 00:00:00:00:00:00 illegal value > > Signed-off-by: Fabio Estevam I tried to apply this but it breaks the unit tests. I guess you didn't try "ut dm" in sandbox? https://travis-ci.org/jhershbe/u-boot/builds/660395782 Please test those and update the tests to pass with your change. Thanks, -Joe
Re: [PATCH] net: phy: dp83867: Add SGMII mode type switching
On Tue, Feb 18, 2020 at 6:51 AM Michal Simek wrote:
>
> This patch adds ability to switch beetween two PHY SGMII modes.
> Some hardware, for example, FPGA IP designs may use 6-wire mode
> which enables differential SGMII clock to MAC.
>
> Patch description, dt flags have been done in mainline Linux by
> commit a2111c460c0c ("net: phy: dp83867: Add documentation for SGMII mode
> type")
> and by commit 507ddd5c0d47 ("net: phy: dp83867: Add SGMII mode type
> switching")
>
> Signed-off-by: Michal Simek
Acked-by: Joe Hershberger
Re: [PATCH v2] net: phy: add XFI, USXGMII types to is_10g_interface() helper
On Thu, Jan 9, 2020 at 2:50 AM Alex Marginean wrote: > > The helper is used to reset PHYs on connect and it determines the clause > to use (C22/C45) based on interface type. This fixes 'PHY reset timed out' > warnings in console for USXGMII/XFI PHYs. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger
Re: [PATCH] net: eth-uclass: Do not return error when no MAC is found
On Thu, Jan 9, 2020 at 12:29 PM Fabio Estevam wrote: > > On some i.MX8QXP MEK boards with no MAC address stored, the following > hang is seen: > > Error: ethernet@5b04 address not set. > > (Board hangs) > > One way to avoid this issue is to select CONFIG_NET_RANDOM_ETHADDR, so > that a random MAC is provided and boot proceeds, but the lack of MAC > should not hang the entire system. > > Fix the hang by removing the propagation of error when no MAC is found. > > In this case there are already messages indicating that something > is not correct: > > Error: ethernet@5b04 address not set. > > Error: ethernet@5b04 address 00:00:00:00:00:00 illegal value > eth0: ethernet@5b04 > Error: ethernet@5b04 address 00:00:00:00:00:00 illegal value > > Signed-off-by: Fabio Estevam Acked-by: Joe Hershberger
Re: [PATCH] net: phy: Fix overlong PHY timeout
On Sat, Jan 4, 2020 at 3:56 AM Andre Przywara wrote:
>
> Commit 27c3f70f3b50 ("net: phy: Increase link up delay in
> genphy_update_link()") increased the per-iteration waiting time from
> 1ms to 50ms, without adjusting the timeout counter. This lead to the
> timeout increasing from the typical 4 seconds to over three minutes.
>
> Adjust the timeout counter evaluation by that factor of 50 to bring the
> timeout back to the intended value.
>
> Signed-off-by: Andre Przywara
Acked-by: Joe Hershberger
Re: [PATCH] doc: net: Rewrite network driver documentation
On Sat, Dec 28, 2019 at 9:19 AM Andre Przywara wrote: > > doc/README.drivers.eth seems like a good source for understanding > U-Boot's network subsystem, but is only talking about legacy network > drivers. This is particularly sad as proper documentation would help in > porting drivers over to the driver model. > > Rewrite the document to describe network drivers in the new driver model > world. Most driver callbacks/methods are almost identical in their semantic, > but recv() differs in some important details. > > Also keep some parts of the original text at the end, to help > understanding old drivers. Add some hints on how to port drivers over. > > This also uses the opportunity to reformat the document in reST, on the > way moving it into doc/driver-model and adding it into the structure > there. > > Signed-off-by: Andre Przywara > Reviewed-by: Simon Glass Acked-by: Joe Hershberger
Re: [PATCH 1/2] drivers: net: phy: aquantia: drop XGMII as a valid system interface proto
On Wed, Dec 4, 2019 at 8:06 AM Alex Marginean wrote: > > Use either USXGMII or XFI in aquantia_set_proto and drop XGMII as a valid > protocol configuration. The PHY doesn't support it, it's just used as an > alias for one of the other two protocols. > > Signed-off-by: Florin Chiculita > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger
Re: [PATCH 2/2] drivers: net: phy: aquantia: make it less verbose
On Wed, Dec 4, 2019 at 7:42 AM Alex Marginean wrote: > > The driver now unconditionally prints some information that's not > universally useful. Replace printf with debug. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger
Re: [PATCH v2 12/12] phy: atheros: consolidate {ar8031|ar8035}_config()
On Thu, Dec 5, 2019 at 5:05 PM Michael Walle wrote: > > The two functions are now exactly the same, remove one of them. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger
Re: [PATCH v2 11/12] phy: atheros: ar8035: remove static clock config
On Thu, Dec 5, 2019 at 5:04 PM Michael Walle wrote: > > We can configure the clock output in the device tree. Disable the > hardcoded one in here. This is highly board-specific and should have > never been enabled in the PHY driver. > > If bisecting shows that this commit breaks your board it probably > depends on the clock output of your Atheros AR8035 PHY. Please have a > look at doc/device-tree-bindings/net/phy/atheros.txt. You need to set > "clk-out-frequency = <12500>" because that value was the hardcoded > value until this commit. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger
Re: [PATCH v2 10/12] phy: atheros: add device tree bindings and config
On Thu, Dec 5, 2019 at 5:04 PM Michael Walle wrote: > > Add support for configuring the CLK_25M pin as well as the RGMII I/O > voltage by the device tree. > > By default the AT803x PHYs outputs the 25MHz clock of the XTAL input. > But this output can also be changed by software to other frequencies. > This commit introduces a generic way to configure this output. > > Also the PHY supports different RGMII I/O voltages: 1.5V, 1.8V and 2.5V. > An internal LDO is able to provide 1.5V (default) and 1.8V. The 2.5V > option needs an external supply voltage. This commit adds support to > switch the internal LDO to 1.8V. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger
Re: [PATCH v2 09/12] phy: atheros: move delay config to common function
On Thu, Dec 5, 2019 at 5:03 PM Michael Walle wrote: > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger
Re: [PATCH v2 08/12] phy: atheros: introduce debug read and write functions
On Thu, Dec 5, 2019 at 5:00 PM Michael Walle wrote: > > Provide functions to read and write the Atheros debug registers. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger
Re: [PATCH v2 06/12] phy: atheros: fix AR8021 PHY ID mask
On Thu, Dec 5, 2019 at 5:02 PM Michael Walle wrote: > > The upper bits are all the OUI. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger
Re: [U-Boot] [PATCH] net: eth-uclass: Remove warning about ROM MAC address
On Tue, Jan 28, 2020 at 10:33 AM Fabio Estevam wrote: > > Hi Joe, > > Ping > > On Mon, Jan 6, 2020 at 8:32 PM Fabio Estevam wrote: > > > > Hi Joe, > > > > On Wed, Dec 11, 2019 at 8:54 AM Schrempf Frieder > > wrote: > > > > > > On 11.10.19 01:00, Soeren Moch wrote: > > > > Using a MAC address from ROM storage is the normal case for most > > > > ethernet hardware. Why should we warn about this? > > > > > > > > Signed-off-by: Soeren Moch > > > > > > Some months ago I came up with the very same patch and I currently have > > > it in my local fork with the description "Reading the MAC address from > > > ROM is often a standard use case and should not produce a warning". > > > > > > Therefore I'm supporting Soeren's and Fabio's point of view here and I'm > > > in favor of merging this patch or if preferred, change the printf() to > > > debug(). > > > > > > Reviewed-by: Frieder Schrempf > > > > Any feedback, please? Traditionally the env was the source of truth for the MAC, so using the ROM was a fall-back if the env didn't have one. But times change, I guess. I'll pull this into my next PR. Acked-by: Joe Hershberger
Re: [PATCH 1/1] net: tftp: use correct printf codes
On Wed, Jan 1, 2020 at 4:16 PM Heinrich Schuchardt wrote: > > When printing unsigned numbers use %u. > > Signed-off-by: Heinrich Schuchardt Acked-by: Joe Hershberger
Re: [PATCH] drivers: net: bcm-sf2: pass -1 to phy_connect()
On Thu, Dec 19, 2019 at 6:36 AM Alex Marginean wrote: > > Passing 0 to PHY connect used to trigger a MDIO scan due to a bug fixed in > the meantime. It's unclear if bcm-sf2 wants to connect to PHY @ addr 0 or > is scanning the bus, passing -1 here should keep it functional either way. > > Signed-off-by: Alex Marginean > Cc: Jiandong Zheng Acked-by: Joe Hershberger
Re: [PATCH] net: dwc_eth_qos: Pass -1 to phy_connect() to scan for all PHYs
On Wed, Dec 18, 2019 at 12:49 AM Marek Vasut wrote: > > PHY address 0 is a valid PHY address, to scan for all PHYs, pass -1 to > phy_connect(). Passing 0 used to work before be accident, but does no > longer. > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Ramon Fried Acked-by: Joe Hershberger
Re: [U-Boot] [PATCH] net/phy: Fix phy_connect() for phy addr 0
On Tue, Dec 17, 2019 at 11:55 PM Marek Vasut wrote: > > On 12/18/19 3:06 AM, Joe Hershberger wrote: > > On Tue, Dec 17, 2019 at 1:04 PM Marek Vasut wrote: > >> > >> On 12/17/19 7:47 PM, Joe Hershberger wrote: > >>> On Tue, Dec 17, 2019 at 11:46 AM Marek Vasut wrote: > >>>> > >>>> On 12/17/19 5:25 PM, Joe Hershberger wrote: > >>>>> Hi Marek, > >>>> > >>>> Hi Joe, > >>>> > >>>>> On Tue, Dec 17, 2019 at 1:39 AM Marek Vasut wrote: > >>>>>> > >>>>>> On 11/7/19 9:04 PM, Joe Hershberger wrote: > >>>>>>> On Thu, Nov 7, 2019 at 1:16 PM Tom Rini wrote: > >>>>>>>> > >>>>>>>> On Tue, Nov 05, 2019 at 04:05:11AM +, Priyanka Jain wrote: > >>>>>>>> > >>>>>>>>> Fix 'mask' calculation in phy_connect() for phy addr '0'. > >>>>>>>>> 'mask' is getting set to '0x' for phy addr '0' > >>>>>>>>> in phy_connect() whereas expected value is '0'. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Signed-off-by: Priyanka Jain > >>>>>>>> > >>>>>>>> Reported-by: tetsu-aoki via github > >>>>>>> > >>>>>>> Acked-by: Joe Hershberger > >>>>>> > >>>>>> Sadly, this breaks systems where a PHY is at address 0. > >>>>>> I have such an STM32MP1 system with LAN8720 PHY and since this patch, I > >>>>>> cannot use ethernet. Please revert. > >>>>> > >>>>> It seems like a case that shouldn't have worked before. > >>>> > >>>> Eh? PHY at address 0 definitely did work before and must work now. > >>> > >>> Agreed that a phy at address 0 should work. Not agreed that because > >>> the value "0" used to work due to a bug that it must still. Which of > >>> these is the statement you are making? Do we already agree or > >>> disagree? > >> > >> I am saying that because a board worked on rc4 and does not work on rc5, > >> this is a bug introduced by this patch in rc5 and must be fixed before > >> the release. > >> > >> The address 0 is a PHY broadcast address for some PHYs, it's a fixed > >> address for other PHYs. Thus, a PHY at address 0 must work. If this is > >> broken now, it's a bug. > > > > The only thing this patch should change is to not access addresses > > other than 0. I read the data sheet for the LAN8720 and it doesn't > > mention anything about any broadcast behavior, so I'm not sure what > > you're trying to state here. > > Read [1] section 3.7.1 PHYAD[2:0]: PHY ADDRESS CONFIGURATION > > What I am saying is that there are two types of PHYs, ones which treat > PHY address 0 as broadcast and ones which treat it as regular address. > This one is the later and is configured as such in my case. > > http://ww1.microchip.com/downloads/en/DeviceDoc/2164B.pdf I see. What's an example of a phy that treats 0 as broadcast? > >>>>> What about > >>>>> this board requires the mask to be all 'f's, other than specifying the > >>>>> wrong phy address? It seems that in your case the phy address is not > >>>>> actually 0 (or the computed mask would find it), but your board dts > >>>>> may be setting it to 0 as an "unknown" value, but the correct unknown > >>>>> value should be "-1". It seems the issue is with these boards. > >>>> > >>>> Nope, the address is actually configured to 0 in hardware. > >>> > >>> Can you double check that? > >> > >> No, sorry, I know the hardware is fixed to 0. Checking it again will not > >> change this fact. > > > > It seems there is no phy driver for this in U-Boot so the generic > > behavior is being used. I'm at a disadvantage of not having this board > > to try. Can you revert this patch and run with debug enabled for > > drivers/net/phy/phy.c to determine what is happening for this board? I > > would appreciate you helping with this. > > It only says "connected to Generic PHY" . > > So looking at the commit message, I am not really sure which board or > issue does this patch fix. But if I understand the commit message right, > then the aim is to set mask to 0 instead of 0x for address 0. > But that's not right either, the mask should be BIT(0) = 1 for address > 0, and that's what the patch actually does. I guess this then fails > somewhere further down the road ... Yes, the commit message is wrong... the expected value is 1, not 0. I missed that in the review. Is the patch you sent earlier a solution for your board or something unrelated you found as a result of this discussion?
Re: [U-Boot] [PATCH] net/phy: Fix phy_connect() for phy addr 0
On Tue, Dec 17, 2019 at 1:04 PM Marek Vasut wrote: > > On 12/17/19 7:47 PM, Joe Hershberger wrote: > > On Tue, Dec 17, 2019 at 11:46 AM Marek Vasut wrote: > >> > >> On 12/17/19 5:25 PM, Joe Hershberger wrote: > >>> Hi Marek, > >> > >> Hi Joe, > >> > >>> On Tue, Dec 17, 2019 at 1:39 AM Marek Vasut wrote: > >>>> > >>>> On 11/7/19 9:04 PM, Joe Hershberger wrote: > >>>>> On Thu, Nov 7, 2019 at 1:16 PM Tom Rini wrote: > >>>>>> > >>>>>> On Tue, Nov 05, 2019 at 04:05:11AM +, Priyanka Jain wrote: > >>>>>> > >>>>>>> Fix 'mask' calculation in phy_connect() for phy addr '0'. > >>>>>>> 'mask' is getting set to '0x' for phy addr '0' > >>>>>>> in phy_connect() whereas expected value is '0'. > >>>>>>> > >>>>>>> > >>>>>>> Signed-off-by: Priyanka Jain > >>>>>> > >>>>>> Reported-by: tetsu-aoki via github > >>>>> > >>>>> Acked-by: Joe Hershberger > >>>> > >>>> Sadly, this breaks systems where a PHY is at address 0. > >>>> I have such an STM32MP1 system with LAN8720 PHY and since this patch, I > >>>> cannot use ethernet. Please revert. > >>> > >>> It seems like a case that shouldn't have worked before. > >> > >> Eh? PHY at address 0 definitely did work before and must work now. > > > > Agreed that a phy at address 0 should work. Not agreed that because > > the value "0" used to work due to a bug that it must still. Which of > > these is the statement you are making? Do we already agree or > > disagree? > > I am saying that because a board worked on rc4 and does not work on rc5, > this is a bug introduced by this patch in rc5 and must be fixed before > the release. > > The address 0 is a PHY broadcast address for some PHYs, it's a fixed > address for other PHYs. Thus, a PHY at address 0 must work. If this is > broken now, it's a bug. The only thing this patch should change is to not access addresses other than 0. I read the data sheet for the LAN8720 and it doesn't mention anything about any broadcast behavior, so I'm not sure what you're trying to state here. > >>> What about > >>> this board requires the mask to be all 'f's, other than specifying the > >>> wrong phy address? It seems that in your case the phy address is not > >>> actually 0 (or the computed mask would find it), but your board dts > >>> may be setting it to 0 as an "unknown" value, but the correct unknown > >>> value should be "-1". It seems the issue is with these boards. > >> > >> Nope, the address is actually configured to 0 in hardware. > > > > Can you double check that? > > No, sorry, I know the hardware is fixed to 0. Checking it again will not > change this fact. It seems there is no phy driver for this in U-Boot so the generic behavior is being used. I'm at a disadvantage of not having this board to try. Can you revert this patch and run with debug enabled for drivers/net/phy/phy.c to determine what is happening for this board? I would appreciate you helping with this. > > The code as is should compute a mask of > > "0x01" which should match the offset for address 0. If it really is at > > 0 in hardware, maybe there is a different bug. Otherwise I don't see > > how this patch would work for the author. > > Reverting this patch makes things work again for me.
Re: [U-Boot] [PATCH] net/phy: Fix phy_connect() for phy addr 0
On Tue, Dec 17, 2019 at 11:46 AM Marek Vasut wrote: > > On 12/17/19 5:25 PM, Joe Hershberger wrote: > > Hi Marek, > > Hi Joe, > > > On Tue, Dec 17, 2019 at 1:39 AM Marek Vasut wrote: > >> > >> On 11/7/19 9:04 PM, Joe Hershberger wrote: > >>> On Thu, Nov 7, 2019 at 1:16 PM Tom Rini wrote: > >>>> > >>>> On Tue, Nov 05, 2019 at 04:05:11AM +, Priyanka Jain wrote: > >>>> > >>>>> Fix 'mask' calculation in phy_connect() for phy addr '0'. > >>>>> 'mask' is getting set to '0x' for phy addr '0' > >>>>> in phy_connect() whereas expected value is '0'. > >>>>> > >>>>> > >>>>> Signed-off-by: Priyanka Jain > >>>> > >>>> Reported-by: tetsu-aoki via github > >>> > >>> Acked-by: Joe Hershberger > >> > >> Sadly, this breaks systems where a PHY is at address 0. > >> I have such an STM32MP1 system with LAN8720 PHY and since this patch, I > >> cannot use ethernet. Please revert. > > > > It seems like a case that shouldn't have worked before. > > Eh? PHY at address 0 definitely did work before and must work now. Agreed that a phy at address 0 should work. Not agreed that because the value "0" used to work due to a bug that it must still. Which of these is the statement you are making? Do we already agree or disagree? > > What about > > this board requires the mask to be all 'f's, other than specifying the > > wrong phy address? It seems that in your case the phy address is not > > actually 0 (or the computed mask would find it), but your board dts > > may be setting it to 0 as an "unknown" value, but the correct unknown > > value should be "-1". It seems the issue is with these boards. > > Nope, the address is actually configured to 0 in hardware. Can you double check that? The code as is should compute a mask of "0x01" which should match the offset for address 0. If it really is at 0 in hardware, maybe there is a different bug. Otherwise I don't see how this patch would work for the author. Thanks, -Joe
Re: [U-Boot] [PATCH] net/phy: Fix phy_connect() for phy addr 0
Hi Marek, On Tue, Dec 17, 2019 at 1:39 AM Marek Vasut wrote: > > On 11/7/19 9:04 PM, Joe Hershberger wrote: > > On Thu, Nov 7, 2019 at 1:16 PM Tom Rini wrote: > >> > >> On Tue, Nov 05, 2019 at 04:05:11AM +, Priyanka Jain wrote: > >> > >>> Fix 'mask' calculation in phy_connect() for phy addr '0'. > >>> 'mask' is getting set to '0x' for phy addr '0' > >>> in phy_connect() whereas expected value is '0'. > >>> > >>> > >>> Signed-off-by: Priyanka Jain > >> > >> Reported-by: tetsu-aoki via github > > > > Acked-by: Joe Hershberger > > Sadly, this breaks systems where a PHY is at address 0. > I have such an STM32MP1 system with LAN8720 PHY and since this patch, I > cannot use ethernet. Please revert. It seems like a case that shouldn't have worked before. What about this board requires the mask to be all 'f's, other than specifying the wrong phy address? It seems that in your case the phy address is not actually 0 (or the computed mask would find it), but your board dts may be setting it to 0 as an "unknown" value, but the correct unknown value should be "-1". It seems the issue is with these boards. Cheers, -Joe
Re: [PATCH 1/1] common: remove duplicate typedef for uchar
Hi Heinrich,
On Tue, Dec 10, 2019 at 12:44 AM Heinrich Schuchardt wrote:
>
> With commit 37db55b7e9db ("linux/types.h: fix typo unchar") we have a
> duplicate typedef for uchar. As linux/types.h is included in common.h we
> don't need another typedef for uchar there.
>
> Fixes: 37db55b7e9db ("linux/types.h: fix typo unchar")
> Signed-off-by: Heinrich Schuchardt
Reviewed-by: Joe Hershberger
Re: Pull request: u-boot-net.git master
Hi Tom, On Mon, Dec 9, 2019 at 4:49 PM Tom Rini wrote: > > On Mon, Dec 09, 2019 at 09:51:32AM -0600, Joe Hershberger wrote: > > > Hi Tom, > > > > Between dropping the superceeded atheros series and applying your nfs trim > > patch, things appear to be all good. > > > > Passed testing at https://travis-ci.org/jhershbe/u-boot/builds/622465407 > > > > The following changes since commit b38c3a641fc01fcd4eda5fa107ae3c247baa0196: > > > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2019-12-08 > > 10:51:00 -0500) > > > > are available in the git repository at: > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-net.git master > > > > for you to fetch changes up to 2c4e067d493d031d1267eea1c635d1eab93ce8f7: > > > > cmd: pxe: Increase maximum path length (2019-12-09 09:49:48 -0600) > > > > > > Alex Marginean (18): > > include: phy: define XFI and USXGMII interface types > > include: phy: add data field for private driver data > > drivers: net: aquantia: use XFI, USXGMII interface types > > drivers: net: aquantia: add PHY generation information > > drivers: net: aquantia: set up SI protocol based on interface type > > drivers: net: aquantia: set MDI reversal based on DT property > > drivers: net: aquantia: set SMBus addr based on DT property > > drivers: net: aquantia: check system interface too when checking for > > link up > > doc: bindings: add bindings document for PHY nodes > > doc: bindings: Aquantia PHY node binding > > drivers: net: fsl_enetc: use XFI, USXGMII interface type macros > > net: mdio-uclass: rename arguments of dm_mdio_phy_connect for clarity > > net: mdio-uclass: add dm_eth_phy_connect helper function > > drivers: net: fsl_enetc: use the new MDIO DM helper functions > > drivers: net: fsl_enetc: Add 2.5Gbps to supported link speeds > > drivers: net: fsl_enetc: move PCS and PHY config to probe > > drivers: net: fsl_enetc_mdio: return with time-out if HW is stuck > > drivers: net: fsl_enetc: register internal MDIO bus > > > > Anatolij Gustschin (5): > > net: phy: mv88e61xx: rework to enable detection of 88E6071 devices > > net: phy: mv88e61xx: add CPU port parameter init for 88E6071 > > net: phy: mv88E61xx: fix ENERGY_DET init for mv88E6071 > > net: phy: mv88e61xx: register phy_driver struct for 88E6071 > > net: phy: fix switch vendor name > > > > Andre Przywara (1): > > net: tftp: Fix too small block size > > > > Ben Wolsieffer (1): > > cmd: pxe: Increase maximum path length > > > > Bin Meng (1): > > net: tftp: Fix tftp store address check in store_block() > > > > Cédric Le Goater (1): > > net: ftgmac100: align RX/TX descriptors on ARCH_DMA_MINALIGN > > > > Florin Chiculita (1): > > net: phy: aquantia: wait for phy init sequence to finish > > > > Grygorii Strashko (8): > > net: phy: ti: rename ti.c to dp83867.c > > net: phy: dp83867: move static initialization to .probe() > > dt-bindings: phy: dp83867: Add documentation for disabling clock > > output > > net: phy: dp83867: Add ability to disable output clock > > net: phy: dp83867: rework delay rgmii delay handling > > net: phy: dp83867: io impedance is not dependent on RGMII delay > > net: phy: dp83867: refactor rgmii configuration > > arm: dts: k3-am654-base-board-u-boot: change cpsw2g interface mode to > > rgmii-rxid > > > > Grzegorz Jaszczyk (1): > > net: mvpp2: mark phy as invalid in case of missing appropriate driver > > > > Heinrich Schuchardt (1): > > net: avoid address-of-packed-member error > > > > Joe Hershberger (3): > > net: Always build the string_to_enetaddr() helper > > net: Improve documentation for string_to_ip() > > lib: Always build support for formatting MAC and IP address > > > > Josef Holzmayr (2): > > net: macb: explicitly pass phy_adr to mdio read and write > > net: macb: let miiphy_read/_write pass arbitrary addresses > > > > Michael Walle (1): > > net: eth-uclass: ignore unavailable devices > > > > Nevo Hed (3): > > arm: dts: armada-cp110-*dtsi: add xmdio nodes > > net: mvpp2: use new MVMDIO driver > > net: mvpp2: MVPP2 now needs MVMDIO > > > >
Re: [U-Boot] [PATCH 1/9] phy: atheros: introduce debug read and write functions
Hi Tom, On Mon, Dec 9, 2019 at 12:47 PM Tom Rini wrote: > > On Mon, Dec 09, 2019 at 07:42:00PM +0100, Michael Walle wrote: > > Hi Tom, Hi Joe, > > > > Am 2019-12-06 00:58, schrieb Tom Rini: > > > On Fri, Dec 06, 2019 at 12:27:39AM +0100, Michael Walle wrote: > > > > Hi Joe, Hi Tom, > > > > > > > > Am 2019-12-05 16:55, schrieb Joe Hershberger: > > > > > Hi Michael, > > > > > > > > > > On Fri, Oct 25, 2019 at 7:28 PM Michael Walle > > > > > wrote: > > > > > > > > > > > > Provide functions to read and write the Atheros debug registers. > > > > > > > > > > > > Signed-off-by: Michael Walle > > > > > > > > > > This series is adding too much size to several of the boards' SPL it > > > > > seems. > > > > > > > > > > https://travis-ci.org/jhershbe/u-boot/builds/620804934 > > > > > > > > > > Please address this and resend. > > > > > > > > So first of all, this was the old series. There was a v2 series, but > > > > unfortunately, I've forgot to add the mailing to the recipients, so it > > > > never ended up in the patchwork system. sorry :( > > > > > > > > I've resend the v2 series here: > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=146771 > > > > > > > > Now coming to the real problem here. The sizes, or like some boards > > > > handle > > > > the SPL stuff. Btw. I could not reproduce it on the > > > > am335x_boneblack_vboot > > > > board with a gcc-8. I've seen the travis ci job uses the gcc-7 so > > > > this also > > > > depends on the gcc. gcc-8 seems to produce smaller code, because on > > > > the > > > > am335x_evm the overflow was only by some 100 bytes. > > > > > > > > So taking the am335x_evm board for example. It has the following > > > > options > > > > set: > > > > CONFIG_DM_ETH=y > > > > CONFIG_SPL_NET_SUPPORT=y > > > > CONFIG_PHY_ATHEROS=y (this one is set in the config.h!) > > > > > > > > So adding a new binding for the phy obviously increases the code > > > > size. But > > > > the hard question is, how could that be fixed. IMHO the board has > > > > wrong > > > > settings. I really don't know how that could be "fixed" other than not > > > > applying this series. Well, we could make the additions conditional > > > > and > > > > introduce a new Kconfig setting, but that is a relly ugly hack and > > > > won't > > > > last long, would it? Doh! > > > > > > So, the gcc-7 from kernel.org is the min required and must work > > > toolchain. Maybe once gcc-9 is mature enough for people to have made > > > stand-alone toolchains for it we'll move up to that but gcc-8 for > > > everyone ends up being too hard. For the boneblack_vboot config, we > > > could just drop SPL networking, it's not super critical to that > > > particular example. But am335x_evm is the kitchen-sink EVM and it is > > > used and supported there. > > > > > > That said, looking over the u-boot-spl.map, it looks like nfs stuff > > > doesn't get discarded for some reason, I'm going to look in to that. > > > > So do I need to do something now? I guess removing the NFS stuff will > > make enough room to fit this. But how do we make sure, it will be applied > > with this series? > > In this case, Joe has it in the -net PR right now. Thanks! It's actually excluded from the PR. I need to go back and review the rest of the v2 series. Cheers, -Joe
Re: [U-Boot] [PATCH] phy: atheros: add some debug output
Hi Michael, On Sun, Oct 27, 2019 at 3:38 PM Michael Walle wrote: > > The network driver has to set the PHY node correctly. If that is not the > case, ar803x_of_init() will fail. Add some debugging output. > > If the device tree binding is not working for you have a look at the > ar803x_of_init: found PHY node: phy@0 > output. In the case above "phy@0" is the phy node in the device tree. If > instead the node of your network device is displayed, you have to set > the phydev->node property in your network device driver. For example, > the following patch adds it to the fsl_enetc driver: > https://patchwork.ozlabs.org/patch/1184523/ > > Signed-off-by: Michael Walle This doesn't apply so I assume it's either superseded or not needed any more. If those are not the case, please rebase and resend on top of u-boot-net/master Thanks, -Joe
Re: [PATCH] net: nfs: Only link in NFS code outside of SPL builds
On Thu, Dec 5, 2019 at 6:36 PM Tom Rini wrote: > > While we have networking use cases within SPL we do not support loading > files via NFS at this point in time. Disable calling nfs_start() so > that the NFS related code can be garbage collected at link time. > > Cc: Joe Hershberger > Signed-off-by: Tom Rini Acked-by: Joe Hershberger
Re: [U-Boot] [PATCH] cmd: pxe: Increase maximum path length
On Tue, Dec 3, 2019 at 6:35 AM Ben Wolsieffer wrote:
>
> On NixOS, cross compiled kernels have long suffixes that cause them to
> exceed the current maximum path length. The PXE/TFTP max path length is
> used for extlinux.conf support as well, which is where this problem
> usually manifest's itself.
>
> Signed-off-by: Ben Wolsieffer
We'll try it and see if it blows any memory limits.
Acked-by: Joe Hershberger
>
> ---
>
> cmd/pxe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cmd/pxe.c b/cmd/pxe.c
> index 2059975446..744cd82730 100644
> --- a/cmd/pxe.c
> +++ b/cmd/pxe.c
> @@ -21,7 +21,7 @@
> #include "menu.h"
> #include "cli.h"
>
> -#define MAX_TFTP_PATH_LEN 127
> +#define MAX_TFTP_PATH_LEN 512
>
> const char *pxe_default_paths[] = {
> #ifdef CONFIG_SYS_SOC
> --
> 2.24.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] net: avoid address-of-packed-member error
On Thu, Dec 5, 2019 at 1:19 AM Heinrich Schuchardt wrote: > > On 11/6/19 12:07 AM, Joe Hershberger wrote: > > On Tue, Nov 5, 2019 at 5:49 AM Heinrich Schuchardt > > wrote: > >> > >> sandbox_defconfig does not compile using GCC 9.2.1: > >> > >> net/net.c: In function ‘net_process_received_packet’: > >> net/net.c:1288:23: error: taking address of packed member of ‘struct > >> ip_udp_hdr’ may result in an unaligned pointer value > >> [-Werror=address-of-packed-member] > >> 1288 |sumptr = (ushort *)&(ip->udp_src); > >>| ^~ > >> > >> Avoid the error by using a u8 pointer instead of an u16 pointer and > >> in-lining ntohs(). > > > > Seems reasonable. > > > >> Simplify the checksumming of the last message byte. > >> > >> Signed-off-by: Heinrich Schuchardt > > > > Acked-by: Joe Hershberger > > > > Hello Joe, > > this patch did not yet make it into > https://gitlab.denx.de/u-boot/custodians/u-boot-net/commits/master > > Is there something that needs to be changed? No, it is among the patches I'm currently testing [1]. [1] - https://github.com/jhershbe/u-boot/commits/travis_ci/test_1184510 Cheers, -Joe
Re: [U-Boot] [PATCH 1/9] phy: atheros: introduce debug read and write functions
Hi Michael, On Fri, Oct 25, 2019 at 7:28 PM Michael Walle wrote: > > Provide functions to read and write the Atheros debug registers. > > Signed-off-by: Michael Walle This series is adding too much size to several of the boards' SPL it seems. https://travis-ci.org/jhershbe/u-boot/builds/620804934 Please address this and resend. Thanks, -Joe
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
Hey Tom, On Tue, Dec 3, 2019 at 11:05 AM Tom Rini wrote: > > On Tue, Dec 03, 2019 at 10:45:44AM -0600, Joe Hershberger wrote: > > Hi Tom, > > > > On Mon, Dec 2, 2019 at 9:11 PM Tom Rini wrote: > > > > > > Hey all, > > > > > > It's release day and here is v2020.01-rc4. Yes, I'm still working on > > > fixing all of the issues that pop up as I get the MTD clean-up series > > > ready to go. In fact, what I need to do at this point is grab the > > > handful of size reduction patches that this has shown are worthwhile, > > > then I can do the MTD series. Then we're down to just fixing up > > > misconversions where things got turned off. > > > > > > Once again, for a changelog, > > > git log --merges v2020.01-rc3..v2020.01-rc4 > > > and as always, I ask for more details in the PRs people send me so I can > > > put them in the merge commit. > > > > > > I'm planning on doing -rc5 on December 23rd with the release scheduled > > > on January 6th. Thanks all! > > > > I have a -net PR just about ready, but there are a few boards failing > > for size. When can I expect the size reduction to drop? > > How much are they failing? You can rebase on top of > WIP/2019-12-03-master-imports and see if that's enough. But also if arm: + tbs2910 +u-boot.imx exceeds file size limit: 1356+ limit: 0x5fc00 bytes 1357+ actual: 0x60c00 bytes 1358+ excess: 0x1000 bytes arm: + am335x_boneblack_vboot 922+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' 923+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 392 bytes 924+make[2]: *** [spl/u-boot-spl] Error 1 925+make[1]: *** [spl/u-boot-spl] Error 2 926+make: *** [sub-make] Error 2 927 arm: + am335x_evm 928+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.u_boot_list' will not fit in region `.sram' 929+arm-linux-gnueabi-ld.bfd: region `.sram' overflowed by 664 bytes 930+make[2]: *** [spl/u-boot-spl] Error 1 931+make[1]: *** [spl/u-boot-spl] Error 2 932+make: *** [sub-make] Error 2 > it's for packed member things, I'm not sure if that's the right approach > vs disabling the warning like the Linux kernel does (and we do today, > for clang). > > -- > Tom
Re: [U-Boot-Custodians] [ANN] U-Boot v2020.01-rc4 released
Hi Tom, On Mon, Dec 2, 2019 at 9:11 PM Tom Rini wrote: > > Hey all, > > It's release day and here is v2020.01-rc4. Yes, I'm still working on > fixing all of the issues that pop up as I get the MTD clean-up series > ready to go. In fact, what I need to do at this point is grab the > handful of size reduction patches that this has shown are worthwhile, > then I can do the MTD series. Then we're down to just fixing up > misconversions where things got turned off. > > Once again, for a changelog, > git log --merges v2020.01-rc3..v2020.01-rc4 > and as always, I ask for more details in the PRs people send me so I can > put them in the merge commit. > > I'm planning on doing -rc5 on December 23rd with the release scheduled > on January 6th. Thanks all! I have a -net PR just about ready, but there are a few boards failing for size. When can I expect the size reduction to drop? Thanks, -Joe
Re: [U-Boot] [RESEND PATCH] net: tftp: Fix tftp store address check in store_block()
Hi Bin,
On Sun, Dec 1, 2019 at 7:46 PM Bin Meng wrote:
>
> Hi Joe,
>
> On Wed, Nov 20, 2019 at 5:54 AM Joe Hershberger
> wrote:
> >
> > On Sat, Nov 16, 2019 at 12:20 AM Bin Meng wrote:
> > >
> > > During testing of qemu-riscv32 with a 2GiB memory configuration,
> > > tftp always fails with a error message:
> > >
> > > Load address: 0x8400
> > > Loading: #
> > > TFTP error: trying to overwrite reserved memory...
> > >
> > > It turns out the result of 'tftp_load_addr + tftp_load_size' just
> > > overflows (0x1) and the test logic in store_block() fails.
> > > Fix this by adjusting the end address to ULONG_MAX when overflow
> > > is detected.
> > >
> > > Fixes: a156c47e39ad ("tftp: prevent overwriting reserved memory")
> > > Signed-off-by: Bin Meng
> >
> > Odd corner case, but sure...
> >
> > Acked-by: Joe Hershberger
>
> Could you pull this for v2020.01? thanks!
Yep, working on it!
I'm currently looking for the patches that are causing sizes to expand
beyond linking on a few targets.
Cheers,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: tftp: Fix too small block size
On Sat, Nov 23, 2019 at 11:59 AM Andre Przywara wrote:
>
> Commit b618b3707633 ("net: Convert CONFIG_TFTP_BLOCKSIZE to Kconfig")
> accidentally set the default *option* TFTP block size to 512 bytes, even
> though the comment in the code says that this is a terrible choice. Most
> boards didn't define the symbol before, so they got the default block size
> of 1468 bytes before, but now use 512 bytes, which is also the fallback.
> This leads to both abysmal performance and a lot of hashes printed
> on the screen (one character for every 5K), which is both annoying and
> slow over serial links.
>
> Set the default block size in Kconfig back to the value it had before.
>
> This improves TFTP performance from 2.8 MB/s to 6.9 MB/s on a Pine64.
>
> Fixes: b618b3707633 ("net: Convert CONFIG_TFTP_BLOCKSIZE to Kconfig")
> Signed-off-by: Andre Przywara
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ftgmac100: align RX/TX descriptors on ARCH_DMA_MINALIGN
On Thu, Nov 28, 2019 at 6:37 AM Cédric Le Goater wrote:
>
> Fixes: e766849713ff ("net: ftgmac100: convert the RX/TX descriptor arrays")
> Signed-off-by: Cédric Le Goater
Acked-by: Joe Hershberger
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: micrel: make sure the factory test bit is cleared
On Wed, Oct 23, 2019 at 5:47 AM wrote: > > From: Nicolas Ferre > > The KSZ8081 PHY has a factory test mode which is set at the de-assertion > of the reset line based on the RXER (KSZ8081RNA/RND) or TXC > (KSZ8081MNX/RNB) pin. If a pull-down is missing, or if the pin has a > pull-up, the factory test mode should be cleared by manually writing a 0 > (according to the datasheet). > Create another ksz8081_config function to handle this case. > > Suggested-by: Antoine Tenart > Signed-off-by: Nicolas Ferre Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: aquantia: wait for phy init sequence to finish
On Mon, Oct 14, 2019 at 9:27 AM Florin Chiculita
wrote:
>
> Aquantia quad-phys may take longer to initialize. This commit adds
> a polling mechanism for a global alarm bit that tells if phy init
> sequence is completed.
>
> Signed-off-by: Florin Chiculita
Acked-by: Joe Hershberger
> ---
> drivers/net/phy/aquantia.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
> index 465ec2d..ae3112c 100644
> --- a/drivers/net/phy/aquantia.c
> +++ b/drivers/net/phy/aquantia.c
> @@ -37,6 +37,9 @@
> #define GLOBAL_FAULT 0xc850
> #define GLOBAL_RSTATUS_1 0xc885
>
> +#define GLOBAL_ALARM_1 0xcc00
> +#define SYSTEM_READY_BIT 0x40
> +
> #define GLOBAL_STANDARD_CONTROL 0x0
> #define SOFT_RESET BIT(15)
> #define LOW_POWER BIT(11)
> @@ -258,6 +261,17 @@ int aquantia_config(struct phy_device *phydev)
> {
> u32 val, id, rstatus, fault;
> u32 reg_val1 = 0;
> + int num_retries = 5;
> +
> + /* check if the system is out of reset and init sequence completed.
I'll be fixing up this comment format.
> +* chip-wide reset for gen1 quad phys takes longer
> +*/
> + while (--num_retries) {
> + rstatus = phy_read(phydev, MDIO_MMD_VEND1, GLOBAL_ALARM_1);
> + if (rstatus & SYSTEM_READY_BIT)
> + break;
> + mdelay(10);
> + }
>
> id = phy_read(phydev, MDIO_MMD_VEND1, GLOBAL_FIRMWARE_ID);
> rstatus = phy_read(phydev, MDIO_MMD_VEND1, GLOBAL_RSTATUS_1);
> --
> 1.9.3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] phy: atheros: consolidate {ar8031|ar8035}_config()
On Fri, Oct 25, 2019 at 7:29 PM Michael Walle wrote: > > The two functions are now exactly the same, remove one of them. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] phy: atheros: ar8035: remove static clock config
On Fri, Oct 25, 2019 at 7:29 PM Michael Walle wrote: > > We can configure the clock output in the device tree. Disable the > hardcoded one in here. This is highly board-specific and should have > never been enabled in the PHY driver. > > If bisecting shows that this commit breaks your board it probably > depends on the clock output of your Atheros AR8035 PHY. Please have a > look at doc/device-tree-bindings/net/phy/atheros.txt. You need to set > "clk-out-frequency = <12500>" because that value was the hardcoded > value until this commit. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] phy: atheros: Add device tree bindings and config
On Fri, Oct 25, 2019 at 7:29 PM Michael Walle wrote: > > Add support for configuring the CLK_25M pin as well as the RGMII I/O > voltage by the device tree. > > By default the AT803x PHYs outputs the 25MHz clock of the XTAL input. > But this output can also be changed by software to other frequencies. > This commit introduces a generic way to configure this output. > > Also the PHY supports different RGMII I/O voltages: 1.5V, 1.8V and 2.5V. > An internal LDO is able to provide 1.5V (default) and 1.8V. The 2.5V > option needs an external supply voltage. This commit adds support to > switch the internal LDO to 1.8V. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] phy: atheros: fix delay configuration
On Fri, Oct 25, 2019 at 7:30 PM Michael Walle wrote: > > The delay_config() code could only set the delay bit. Thus, it could > only enable the delay mode, but not disable it. To make things worse, > the RX delay mode is enabled by default after a hardware reset, so it > could never be disabled. Fix this, by always setting or clearing the > bits. This is also how the linux kernel configures the PHY. > > If bisecting shows that this commit breaks your board you probably have > a wrong PHY interface mode. You probably want the > PHY_INTERFACE_MODE_RGMII_RXID or PHY_INTERFACE_MODE_RGMII_ID mode. > > Signed-off-by: Michael Walle Either the offending dts's are already updated or they will be when this breaks them. It's been 6 months. Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] phy: atheros: ar8035: use phy_{read|write}_mmd()
On Fri, Oct 25, 2019 at 7:31 PM Michael Walle wrote: > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] phy: atheros: don't overwrite debug register values
On Fri, Oct 25, 2019 at 7:30 PM Michael Walle wrote: > > Instead of doing a hard write, do a read-modify-write. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] phy: atheros: ar8035: remove extra delay config
On Fri, Oct 25, 2019 at 7:29 PM Michael Walle wrote: > > Remove the hard-coded delay configuration. The AR8035 config() always > enabled the TX delay mode, although it will be set according to the PHY > interface mode, too. > > If bisecting shows that this commit breaks your board you probably have > a wrong PHY interface mode. You probably want the > PHY_INTERFACE_MODE_RGMII_TXID or PHY_INTERFACE_MODE_RGMII_ID mode. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] phy: atheros: move delay config to common function
On Fri, Oct 25, 2019 at 7:28 PM Michael Walle wrote: > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] phy: atheros: introduce debug read and write functions
On Fri, Oct 25, 2019 at 7:28 PM Michael Walle wrote: > > Provide functions to read and write the Atheros debug registers. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] phy: atheros: add some debug output
On Sun, Oct 27, 2019 at 3:38 PM Michael Walle wrote: > > The network driver has to set the PHY node correctly. If that is not the > case, ar803x_of_init() will fail. Add some debugging output. > > If the device tree binding is not working for you have a look at the > ar803x_of_init: found PHY node: phy@0 > output. In the case above "phy@0" is the phy node in the device tree. If > instead the node of your network device is displayed, you have to set > the phydev->node property in your network device driver. For example, > the following patch adds it to the fsl_enetc driver: > https://patchwork.ozlabs.org/patch/1184523/ > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: eth-uclass: ignore unavailable devices
On Mon, Oct 21, 2019 at 6:03 PM Michael Walle wrote: > > device_probe() may fail in which case the seq_id will be -1. Don't > display these devices during startup. While this is only a cosmetic > change, the return value of eth_initialize() will also change to the > actual number of available devices. The return value is only used in > spl_net to decide whether there are any devices to boot from. So > returning only available devices is also more correct in that case. > > Signed-off-by: Michael Walle Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: macb: let miiphy_read/_write pass arbitrary addresses
On Wed, Oct 2, 2019 at 2:46 PM Josef Holzmayr wrote: > > This allows passing arbitrary addresses through macb_miiphy_read and > macb_miiphy_write, therefore enabling the mii command to access > all mdio bus devices instead of only the defined phy. > > Signed-off-by: Josef Holzmayr Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: macb: explicitly pass phy_adr to mdio read and write
On Wed, Oct 2, 2019 at 2:47 PM Josef Holzmayr wrote: > > To support accessing arbitrary addresses the mii/mdio bus it is > neccesary that the macb_mdio_read and macb_mdio_write functions > do not implicitly use the address of the connected phy. > > The function signature is extended according to the Linux kernel > equivalent. > > Signed-off-by: Josef Holzmayr Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: Increase link up delay in genphy_update_link()
On Mon, Sep 30, 2019 at 3:33 AM Stefan Roese wrote: > > I've noticed that in most cases when genphy_update_link() is called, the > ethernet driver (mt7628-eth in this case) fails with the first ethernet > packets. Resulting in a timeout of the first tftp command. Increasing > the delay in the link check look from 1 to 50 ms and moving it below the > BMSR register read fixes this issue, resulting in a stable ethernet > traffic, even after initial link autonogotiation. > > Signed-off-by: Stefan Roese > Cc: Weijie Gao > Cc: Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: rtl8169: Support RTL-8168c/8111c
On Wed, Sep 11, 2019 at 12:19 PM Thierry Reding wrote: > > From: Thierry Reding > > This version of the RTL-8168 chip can be found on some add-in cards sold > by CSL-Computer GmbH & Co. KG. The chip isn't special in any way, but it > needs to have the ChipCmd register programmed after the DMA descriptors > have been set up, so make sure that happens by adding an entry to the > chip information table. > > Signed-off-by: Thierry Reding Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/5] net: mvpp2: MVPP2 now needs MVMDIO
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Nevo Hed > > Changes to mvpp2.c require the MVMDIO module which in turn uses > DM_MDIO. > > Signed-off-by: Nevo Hed Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 4/5] net: mvpp2: use new MVMDIO driver
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Nevo Hed > > This commit ports mvpp2 to use the recently introduced Marvell MDIO > (MVMDIO) driver. It removes direct interaction with the SMI & XSMI > busses. This commit is based in part on earlier work by > Ken Ma in Marvell's own downstream repo: > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/c81dc39. > > The above refrenced work was based on an MVMDIO implementation that > never made it into U-Boot. With this patch the mvpp2 driver switches > to use the new MVMDIO driver that is based on a more universal > mdio-uclass implementation. > > Signed-off-by: Nevo Hed Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/5] arm: dts: armada-cp110-*dtsi: add xmdio nodes
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Nevo Hed > > Based on upstream-linux > See https://github.com/torvalds/linux/commit/f66b2aff. > > However made the XSMI register window 0x16 (22) bytes per my reading > of the functional spec. Similar commits in Marvels own repo bump it > to 0x200 (512) bytes but I did not see the reasoning for that. > > https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/commit/4d932b4. > > Also added device-name attributes to prevent ambiguity in the `mdio` > command. > > Signed-off-by: Nevo Hed Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/5] net: mvpp2: mark phy as invalid in case of missing appropriate driver
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Grzegorz Jaszczyk > > If the phy doesn't match with any existing u-boot drivers, the phy > framework will connect it to the generic one which uid == > 0x. In this case, act as if the phy wouldn't be declared in > dts. Otherwise, in case of 3310 (for which the driver doesn't exist) > the link is marked as always down. Removing phy entry from dts in case > of 3310 is not a good option because it is required for the > phy_fw_down procedure. > > This patch fixes the issue with the link always down on MCBIN board. > > nhed: added NULL deref test. > > Signed-off-by: Grzegorz Jaszczyk > Reviewed-by: Igal Liberman > Tested-by: Igal Liberman > Signed-off-by: Nevo Hed Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/5] net: mvpp2x: fix traffic stuck after PHY start error
On Thu, Aug 15, 2019 at 5:09 PM wrote: > > From: Stefan Chulski > > Issue: > - Network stuck if autonegotion fails. > > Issue root cause: > > - When autonegotiation fails during port open procedure, the packet > processor configuration does not finish and open procedure exits > with error. > - However, this doesn't prevent u-boot network framework from > calling send and receive procedures. > - Using transmit and receive functions of misconfigured packet > processor will cause traffic to get stuck. > > Fix: > > - Continue packet processor configuration even if autonegotiation > fails. Only error message is triggered in this case. > - Exit transmit and receive functions if there is no PHY link > indication. > - U-boot network framework now calls open procedure again during next > transmit initiation. > > Signed-off-by: Stefan Chulski > Reviewed-by: Igal Liberman > Tested-by: Igal Liberman Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] net: introduce DSA class for Ethernet switches
Hi Alex,
On Mon, Nov 25, 2019 at 9:54 AM Alex Marginean
wrote:
>
> DSA stands for Distributed Switch Architecture and it covers switches that
> are connected to the CPU through an Ethernet link and generally use frame
> tags to pass information about the source/destination ports to/from CPU.
> Front panel ports are presented as regular ethernet devices in U-Boot and
> they are expected to support the typical networking commands.
> DSA switches may be cascaded, DSA class code does not currently support
> this.
Is it expected to eventually retrofit the other switch drivers that we
have in U-Boot to use this?
>
> Signed-off-by: Alex Marginean
> ---
> drivers/net/Kconfig| 13 ++
> include/dm/uclass-id.h | 1 +
> include/dsa.h | 140
Please use include/net/dsa.h
> net/Makefile | 1 +
> net/dsa-uclass.c | 369 +
> 5 files changed, 524 insertions(+)
> create mode 100644 include/dsa.h
> create mode 100644 net/dsa-uclass.c
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 4182897d89..a4157cb122 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -37,6 +37,19 @@ config DM_MDIO_MUX
> This is currently implemented in net/mdio-mux-uclass.c
> Look in include/miiphy.h for details.
>
> +config DM_DSA
> + bool "Enable Driver Model for DSA switches"
> + depends on DM_ETH && DM_MDIO
> + help
> + Enable Driver Model for DSA switches
> +
> + Adds UCLASS_DSA class supporting switches that follow the
> Distributed
> + Switch Architecture (DSA). These switches rely on the presence of a
> + management switch port connected to an Ethernet controller capable
> of
> + receiving frames from the switch. This host Ethernet controller is
> + called "master" and "cpu" in DSA terminology.
> + This is currently implemented in net/dsa-uclass.c
> +
> config MDIO_SANDBOX
> depends on DM_MDIO && SANDBOX
> default y
> diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
> index 0c563d898b..8f37a91488 100644
> --- a/include/dm/uclass-id.h
> +++ b/include/dm/uclass-id.h
> @@ -42,6 +42,7 @@ enum uclass_id {
> UCLASS_DISPLAY, /* Display (e.g. DisplayPort, HDMI) */
> UCLASS_DSI_HOST,/* Display Serial Interface host */
> UCLASS_DMA, /* Direct Memory Access */
> + UCLASS_DSA, /* Distributed (Ethernet) Switch Architecture
> */
> UCLASS_EFI, /* EFI managed devices */
> UCLASS_ETH, /* Ethernet device */
> UCLASS_FIRMWARE,/* Firmware */
> diff --git a/include/dsa.h b/include/dsa.h
> new file mode 100644
> index 00..707a1d7e6f
> --- /dev/null
> +++ b/include/dsa.h
> @@ -0,0 +1,140 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2019 NXP
> + */
> +
> +#ifndef __DSA_H__
> +#define __DSA_H__
> +
> +#include
> +#include
> +#include
> +
> +/**
> + * DSA stands for Distributed Switch Architecture and it is infrastructure
> + * intended to support drivers for Switches that rely on an intermediary
> + * Ethernet device for I/O. These switches may support cascading allowing
> + * them to be arranged as a tree.
> + * DSA is documented in detail in the Linux kernel documentation under
> + * Documentation/networking/dsa/dsa.txt
> + * The network layout of such a switch is shown below:
> + *
> + * |---
> + * | CPU network device (eth0)|
> + *
> + * | + * | |
> + * | |
> + * |tag added by CPU> |
> + * ||
> + * | Switch driver |
> + * ||
> + * |||| ||
> + * |---| |---| |---|
> + * | sw0p0 | | sw0p1 | | sw0p2 |
> + * |---| |---| |---|
> + *
> + * In U-Boot the intent is to allow acces to front panel ports (shown at the
acces -> access
> + * bottom of the picture) though the master Ethernet port (eth0 in the
> picture).
> + * Front panel ports are presented as regular ethernet devices in U-Boot and
ethernet -> Ethernet
> + * they are expected to support the typical networking commands.
> + * In general DSA switches require the use of tags, extra headers added both
> by
> + * software on Tx and by the switch on Rx. These tags carry at a minimum
> port
> + * information and switch information for cascaded set-ups.
> + * In U-Boot these tags are inserted and parsed by the DSA switch driver, the
> + * class code helps with headroom/tailroom for the extra headers.
> + *
> + * TODO:
> + * - handle switch cascading, for now U-Boot only supports stand-alone
> switches.
> + * - put master Eth in
Re: [U-Boot] [PATCH] drivers: net: fsl_enetc: register internal MDIO bus
On Mon, Nov 25, 2019 at 9:58 AM Alex Marginean wrote: > > This bus is used to access internal SoC PHYs. These PHYs are configured > by the ENETC driver directly, but it's useful to have command line access > to this MDIO to debug the system especially when using new external PHYs. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] drivers: net: fsl_enetc_mdio: return with time-out if HW is stuck
On Thu, Nov 14, 2019 at 10:59 AM Alex Marginean wrote: > > On some boards MDIO may get stuck if it detects echo on the line. This is > a know hardware issue, there is a board fix for it. In case we're running > on a board that doesn't have the fix, we don't want to loop here forever > and freeze U-Boot. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] drivers: net: fsl_enetc: Add 2.5Gbps to supported link speeds
On Thu, Nov 14, 2019 at 10:59 AM Alex Marginean wrote: > > The original code enabled link speeds up to 1Gbps, but the interface can > go up to 2.5G, enable that speed to in PHY AN mask. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] drivers: net: fsl_enetc: move PCS and PHY config to probe
On Thu, Nov 14, 2019 at 10:59 AM Alex Marginean wrote: > > This reduces the time needed to establish a link as we don't reset the link > each time the interface is used. Our Link capabilities do not change at > run-time so there is no need to re-apply PHY configuration each time. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/11] drivers: net: fsl_enetc: use XFI, USXGMII interface type macros
On Thu, Nov 14, 2019 at 10:31 AM Alex Marginean wrote: > > Apply 10G PCS init for USXGMII, XFI interface types. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/11] doc: bindings: Aquantia PHY node binding
On Thu, Nov 14, 2019 at 10:34 AM Alex Marginean wrote: > > A couple of optional properties have been introduced for Aquantia PHY > allowing the driver to set up wiring related configuration points that > are otherwise driven by firmware. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/11] doc: bindings: add bindings document for PHY nodes
On Thu, Nov 14, 2019 at 10:33 AM Alex Marginean wrote: > > It defines that PHY nodes must be children on MDIO bus nodes and defines > the only required property in U-Boot, reg. This property along with the > example provided are copied over from Linux. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/11] drivers: net: aquantia: check system interface too when checking for link up
On Thu, Nov 14, 2019 at 10:32 AM Alex Marginean wrote: > > In some cases the link on the system interface of the aquantia PHY comes up > after the link on line interface. The link state loop only checks the line > side, which may result in first packet sent being lost. > Use aquantia_link_is_up instead, which checks both system and line side on > gen 2/3 PHYs to avoid losing the 1st packet. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/11] drivers: net: aquantia: set SMBus addr based on DT property
On Thu, Nov 14, 2019 at 10:31 AM Alex Marginean wrote: > > Aquantia PHYs have a SMBus interface mostly used for debug. The addresses > on this interface are normally set up by PHY firmware, but depending on the > board they may end up not being unique. Add an optional DT property used > to change SMBus address if needed. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/11] drivers: net: aquantia: set MDI reversal based on DT property
On Thu, Nov 14, 2019 at 10:34 AM Alex Marginean wrote: > > MDI pins up to the RJ45 connector may be reversed on the board and the > default PHY configuration applied by firmware may or may not match that. > Add an optional DT property to configure MDI reversal for this case. > > Signed-off-by: Alex Marginean Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
