Re: [U-Boot] [PATCH v4 3/3] cmd: mdio: Add new parameter to access MMD PHY registers
On Mon, Feb 4, 2019 at 5:39 PM Vladimir Oltean wrote: > > On 2/5/19 1:28 AM, Joe Hershberger wrote: > > On Fri, Jan 25, 2019 at 7:12 AM Vladimir Oltean > > wrote: > >> > >> On 25.01.2019 12:12, Carlo Caione wrote: > >>> On 24/01/2019 20:48, Vladimir Oltean wrote: > >>>> On 1/24/19 10:19 PM, Carlo Caione wrote: > >>>>> On 24/01/2019 20:12, Vladimir Oltean wrote: > >>>>>> > >>>> > >>>> I can't completely answer that, TBH I don't even know who is supposed to > >>>> make that distinction. > >>> > >>> In the kernel that distinction is made by the driver itself, hence my > >>> question. See [0]. > >>> > >>>> For Freescale parts that is a call for the MDIO bus driver to make, for > >>>> good or bad (see drivers/net/fm/memac_phy.c where dev_addr is compared > >>>> to MDIO_DEVAD_NONE). > >>> > >>>> And in your patch, phy_write_mmd is only a wrapper over bus->write in > >>>> the end, with some more logic to handle C22 indirection. > >>>> So my question of unifying "mdio rmmd" with "mdio read" translates into: > >>> > >>>> Does it make sense to also handle the check with MDIO_DEVAD_NONE in > >>>> phy_write_mmd, instead of jumping straight ahead to perform indirection? > >>> > >>> Honestly I'm not quite sure of all the possible implications here IMO > >>> the safest bet here is just to follow what's done by the kernel. Maybe > >>> Joe can step in about this. > >>> > >>> In general we have 3 possible cases: > >>> > >>> 1) your driver is doing something non-standard when accessing the MMDs > >>> and we deal with that using the PHY driver hooks > >>> 2) your PHY is C22 and you have to use the indirect method > >>> 3) your PHY is C45 and you can use the direct register reading (mangling > >>> a bit the address apparently) > >>> > >>> The kernel is dealing with all the cases, U-Boot is only dealing with > >>> C22 PHYs (cases 1 and 2) because AFAICT there isn't yet a generic way to > >>> detect if the PHY is C22 or C45. > >>> > >>> I'm not sure if the indirect method works also for C45 PHYs. > >>> > >>>> The goal would then be to just call phy_write_mmd from cmd/mdio.c > >>>> regardless of the target PHY's clause. > >>> > >>> Again I wrote that patch only assuming that we were going to deal with > >>> C22 PHYs. At this point I wonder if the C22 indirect method works also > >>> for C45 PHYs. If that's the case than the phy_write_mmd should already > >>> work regardless of the target PHY clause. > >>> > >>> Cheers. > >>> > >>> [0] > >>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fnet%2Fphy%2Fphy-core.c%23L296&data=02%7C01%7Cvladimir.oltean%40nxp.com%7C826fd741578446f6f36908d68af87b27%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636849197162094704&sdata=r9AlGZbzGtLC2z7u2HgKKZt17Cl1OcHncjeY00xlVWE%3D&reserved=0 > >>> > >> > >> I'm not suggesting to use C22 indirection if the PHY already supports > >> native C45 addressing. Even if that worked, it would be a pointless > >> exercise in all but a few cases (like the MDIO controller does not > >> support C22, but the PHY does support both C22 and C45). > >> I was just wondering out loud whether the introduction of the "mdio > >> rmmd" command is justified or not. I now understand that using e.g. > >> "mdio read 1.3" will confuse the command for clause 45 PHY's because it > >> won't know whether it should access the PHY via native C45 or via > >> indirect C22 (obviously it shouldn't do the latter). So in lack of a > >> clear distinction mechanism, I now think that a new command truly is > >> necessary for performing indirect C45 access on C22. > >> What I am still not convinced of, however, is whether those commands > >> should be called "rmmd" and "wmmd". It is not immediately obvious from > >> the command description that this is what they are for, and a user may > >> attempt to use them for C45 PHY's as well, which will probably not yield > >> the intended result. > > > > I agree. T
Re: [U-Boot] [PATCH 2/3] net: add higmacv300 Ethernet driver for HiSilicon platform
On Mon, Jan 28, 2019 at 3:16 AM Shawn Guo wrote: > > It adds the driver for HIGMACV300 Ethernet controller found on HiSilicon > SoCs like Hi3798CV200. It's based on a downstream U-Boot driver, but > quite a lot of code gets rewritten and cleaned up to adopt driver model > and PHY API. > > Signed-off-by: Shawn Guo > --- > drivers/net/Kconfig | 9 + > drivers/net/Makefile | 1 + > drivers/net/higmacv300.c | 592 +++ > 3 files changed, 602 insertions(+) > create mode 100644 drivers/net/higmacv300.c > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index 39ce4e8a1fc6..e07a382c28c7 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/net/Kconfig > @@ -530,4 +530,13 @@ config MEDIATEK_ETH > This Driver support MediaTek Ethernet GMAC > Say Y to enable support for the MediaTek Ethernet GMAC. > > +config NET_HIGMACV300 > + bool "HiSilicon Gigabit Ethernet Controller" > + depends on DM_ETH > + select DM_RESET > + select PHYLIB > + help > + This driver supports HIGMACV300 Ethernet controller found on > + HiSilicon SoCs. > + > endif # NETDEVICES > diff --git a/drivers/net/Makefile b/drivers/net/Makefile > index e38c16464478..0951cb17e6ba 100644 > --- a/drivers/net/Makefile > +++ b/drivers/net/Makefile > @@ -76,3 +76,4 @@ obj-$(CONFIG_SNI_AVE) += sni_ave.o > obj-y += ti/ > obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o > obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o > +obj-$(CONFIG_NET_HIGMACV300) += higmacv300.o > diff --git a/drivers/net/higmacv300.c b/drivers/net/higmacv300.c > new file mode 100644 > index ..6cac5cec73df > --- /dev/null > +++ b/drivers/net/higmacv300.c > @@ -0,0 +1,592 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2019, Linaro Limited > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define STATION_ADDR_LOW 0x > +#define STATION_ADDR_HIGH 0x0004 > +#define MAC_DUPLEX_HALF_CTRL 0x0008 > +#define PORT_MODE 0x0040 > +#define PORT_EN0x0044 > +#define BIT_TX_EN BIT(2) > +#define BIT_RX_EN BIT(1) > +#define MODE_CHANGE_EN 0x01b4 > +#define BIT_MODE_CHANGE_EN BIT(0) > +#define MDIO_SINGLE_CMD0x03c0 > +#define BIT_MDIO_BUSY BIT(20) > +#define MDIO_SINGLE_DATA 0x03c4 > +#define MDIO_RDATA_STATUS 0x03d0 > +#define BIT_MDIO_RDATA_INVALID BIT(0) > +#define RX_FQ_START_ADDR 0x0500 > +#define RX_FQ_DEPTH0x0504 > +#define RX_FQ_WR_ADDR 0x0508 > +#define RX_FQ_RD_ADDR 0x050c > +#define RX_FQ_REG_EN 0x0518 > +#define RX_BQ_START_ADDR 0x0520 > +#define RX_BQ_DEPTH0x0524 > +#define RX_BQ_WR_ADDR 0x0528 > +#define RX_BQ_RD_ADDR 0x052c > +#define RX_BQ_REG_EN 0x0538 > +#define TX_BQ_START_ADDR 0x0580 > +#define TX_BQ_DEPTH0x0584 > +#define TX_BQ_WR_ADDR 0x0588 > +#define TX_BQ_RD_ADDR 0x058c > +#define TX_BQ_REG_EN 0x0598 > +#define TX_RQ_START_ADDR 0x05a0 > +#define TX_RQ_DEPTH0x05a4 > +#define TX_RQ_WR_ADDR 0x05a8 > +#define TX_RQ_RD_ADDR 0x05ac > +#define TX_RQ_REG_EN 0x05b8 > +#define BIT_START_ADDR_EN BIT(2) > +#define BIT_DEPTH_EN BIT(1) > +#define DESC_WR_RD_ENA 0x05cc > + > +/* MACIF_CTRL */ > +#define RGMII_SPEED_1000 0x2c > +#define RGMII_SPEED_1000x2f > +#define RGMII_SPEED_10 0x2d > +#define MII_SPEED_100 0x0f > +#define MII_SPEED_10 0x0d > +#define GMAC_SPEED_10000x05 > +#define GMAC_SPEED_100 0x01 > +#define GMAC_SPEED_10 0x00 > +#define GMAC_FULL_DUPLEX BIT(4) > + > +#define RX_DESC_NUM64 > +#define TX_DESC_NUM2 > +#define DESC_SIZE 32 > +#define DESC_WORD_SHIFT3 > +#define DESC_BYTE_SHIFT5 > +#define DESC_CNT(n)((n) >> DESC_BYTE_SHIFT) > +#define DESC_BYTE(n) ((n) << DESC_BYTE_SHIFT) > +#define DESC_VLD_FREE 0 > +#define DESC_VLD_BUSY 1 > + > +#define MAC_MAX_FRAME_SIZE 1600 > + > +#define MDIO_WRITE 1 > +#define MDIO_READ 2 > +#define MDIO_COMMAND(rw, addr, reg)(BIT_MDIO_BUSY | \ > + (((rw) & 0x3) << 16) | \ > +
Re: [U-Boot] [PATCH v3 6/6] net: phy: ar803x: Clarify the intention of ar8021_config
On Fri, Jan 25, 2019 at 6:42 PM Vladimir Oltean wrote: > > Debug register 5 contains TX_CLK DELAY at bit 8 and reserved values at > the other bit positions, just like the other PHYs in the family do. > Therefore, it is not necessary to hardcode the reserved values, but > instead simply follow the read-modify-write procedure from the common > function. > > Signed-off-by: Vladimir Oltean 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 5/6] net: phy: ar803x: Clarify the configuration of the CLK_25M output pin
On Fri, Jan 25, 2019 at 6:43 PM Vladimir Oltean wrote: > > Also take the opportunity to use the phy_read_mmd and phy_write_mmd > convenience functions. > > Signed-off-by: Vladimir Oltean 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 4/6] net: phy: ar803x: Explicitly disable RGMII delays
On Fri, Jan 25, 2019 at 6:43 PM Vladimir Oltean wrote: > > To eliminate any doubts about the out-of-reset value of the PHY, that > the driver previously relied on. > > Signed-off-by: Vladimir Oltean 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 3/6] net: phy: ar803x: Use common functions for RGMII internal delays
On Fri, Jan 25, 2019 at 6:42 PM Vladimir Oltean wrote: > > Signed-off-by: Vladimir Oltean 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 2/6] net: phy: ar803x: Make RGMII Tx delays actually configurable for AR8035
On Fri, Jan 25, 2019 at 6:41 PM Vladimir Oltean wrote: > > Delete the extraneous write to debug reg 5 that enables Tx delay > > When the driver was originally introduced in commit "6027384a phylib: > Add Atheros AR8035 GETH PHY support", the Tx delay was being > unconditionally enabled. > > Then during "2ec4d10b phy: atheros: add support for RGMII_ID, RGMII_TXID > and RGMII_RXID", the author did not notice that code for enabling Tx > delay code was already. Therefore, the if condition for Tx delay has > always been useless for this PHY since this commit introduced it. > > Prior to this patch, every AR8035 PHY in U-boot had Tx delay enabled. > After this patch, only those who define the interface as RGMII_TXID or > RGMII_ID will. This is to be expected, but will nonetheless break the > setups of those who didn't know they rely on Tx delay implicitly. > > Signed-off-by: Vladimir Oltean > --- 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/3] cmd: mdio: Add new parameter to access MMD PHY registers
On Fri, Jan 25, 2019 at 7:12 AM Vladimir Oltean wrote: > > On 25.01.2019 12:12, Carlo Caione wrote: > > On 24/01/2019 20:48, Vladimir Oltean wrote: > >> On 1/24/19 10:19 PM, Carlo Caione wrote: > >>> On 24/01/2019 20:12, Vladimir Oltean wrote: > > >> > >> I can't completely answer that, TBH I don't even know who is supposed to > >> make that distinction. > > > > In the kernel that distinction is made by the driver itself, hence my > > question. See [0]. > > > >> For Freescale parts that is a call for the MDIO bus driver to make, for > >> good or bad (see drivers/net/fm/memac_phy.c where dev_addr is compared > >> to MDIO_DEVAD_NONE). > > > >> And in your patch, phy_write_mmd is only a wrapper over bus->write in > >> the end, with some more logic to handle C22 indirection. > >> So my question of unifying "mdio rmmd" with "mdio read" translates into: > > > >> Does it make sense to also handle the check with MDIO_DEVAD_NONE in > >> phy_write_mmd, instead of jumping straight ahead to perform indirection? > > > > Honestly I'm not quite sure of all the possible implications here IMO > > the safest bet here is just to follow what's done by the kernel. Maybe > > Joe can step in about this. > > > > In general we have 3 possible cases: > > > > 1) your driver is doing something non-standard when accessing the MMDs > > and we deal with that using the PHY driver hooks > > 2) your PHY is C22 and you have to use the indirect method > > 3) your PHY is C45 and you can use the direct register reading (mangling > > a bit the address apparently) > > > > The kernel is dealing with all the cases, U-Boot is only dealing with > > C22 PHYs (cases 1 and 2) because AFAICT there isn't yet a generic way to > > detect if the PHY is C22 or C45. > > > > I'm not sure if the indirect method works also for C45 PHYs. > > > >> The goal would then be to just call phy_write_mmd from cmd/mdio.c > >> regardless of the target PHY's clause. > > > > Again I wrote that patch only assuming that we were going to deal with > > C22 PHYs. At this point I wonder if the C22 indirect method works also > > for C45 PHYs. If that's the case than the phy_write_mmd should already > > work regardless of the target PHY clause. > > > > Cheers. > > > > [0] > > https://elixir.bootlin.com/linux/latest/source/drivers/net/phy/phy-core.c#L296 > > > > I'm not suggesting to use C22 indirection if the PHY already supports > native C45 addressing. Even if that worked, it would be a pointless > exercise in all but a few cases (like the MDIO controller does not > support C22, but the PHY does support both C22 and C45). > I was just wondering out loud whether the introduction of the "mdio > rmmd" command is justified or not. I now understand that using e.g. > "mdio read 1.3" will confuse the command for clause 45 PHY's because it > won't know whether it should access the PHY via native C45 or via > indirect C22 (obviously it shouldn't do the latter). So in lack of a > clear distinction mechanism, I now think that a new command truly is > necessary for performing indirect C45 access on C22. > What I am still not convinced of, however, is whether those commands > should be called "rmmd" and "wmmd". It is not immediately obvious from > the command description that this is what they are for, and a user may > attempt to use them for C45 PHY's as well, which will probably not yield > the intended result. I agree. The MMD in the register name is simply "MDIO Manageable Devices"... i.e. the phys. I think the commands should be "iread" and "iwrite" to denote the indirect access in use. Thanks, -Joe > ___ > 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 v2 3/3] net: phy: ar803x: Use common functions for RGMII internal delays
On Thu, Jan 24, 2019 at 6:35 PM Vladimir Oltean wrote:
>
> On 1/24/19 8:20 AM, Joe Hershberger wrote:
> > On Wed, Jan 23, 2019 at 5:47 PM Vladimir Oltean
> > wrote:
> >> static int ar8021_config(struct phy_device *phydev)
> >> {
> >> phy_write(phydev, MDIO_DEVAD_NONE, 0x00, 0x1200);
> >> - phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
> >> - phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x3D47);
> >> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG,
> >> + AR803x_DEBUG_REG_5);
> >> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG,
> >> 0x3D47);
> >
> > While this patch is an improvement on the former state, can we add a
> > comment on the magic number or define a constant?
> >
> I have no idea what 0x3D47 is, sorry. I couldn't find any public AR8021
> register map either. For the other PHYs in this family, debug register 5
> holds TX_CLK_DELAY at bit 8. No idea of the implications of writing the
> other bits. Will act on the rest of your comments.
OK, thanks.
> -Vladimir
> ___
> 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 v2 1/3] net: phy: ar803x: Use phy_read_mmd and phy_write_mmd functions
On Thu, Jan 24, 2019 at 6:35 PM Vladimir Oltean wrote:
>
> On 1/24/19 8:16 AM, Joe Hershberger wrote:
> > On Wed, Jan 23, 2019 at 5:46 PM Vladimir Oltean
> > wrote:
> >>
> >> Signed-off-by: Vladimir Oltean
> >> ---
> >> Changes in v2:
> >> * Patch added in this version.
> >>
> >> drivers/net/phy/atheros.c | 8 +++-
> >> 1 file changed, 3 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
> >> index 3783d15..b4066e3 100644
> >> --- a/drivers/net/phy/atheros.c
> >> +++ b/drivers/net/phy/atheros.c
> >> @@ -57,11 +57,9 @@ static int ar8035_config(struct phy_device *phydev)
> >> {
> >> int regval;
> >>
> >> - phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x0007);
> >> - phy_write(phydev, MDIO_DEVAD_NONE, 0xe, 0x8016);
> >> - phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007);
> >> - regval = phy_read(phydev, MDIO_DEVAD_NONE, 0xe);
> >> - phy_write(phydev, MDIO_DEVAD_NONE, 0xe, (regval|0x0018));
> >> + /* CLK_25M output clock select: 125 MHz */
> >> + regval = phy_read_mmd(phydev, MDIO_MMD_AN, 0x8016);
> >> + phy_write_mmd(phydev, MDIO_MMD_AN, 0x8016, regval | 0x0018);
> >
> > I think I see how the old code accomplished the same thing. It was
> > woefully undocumented. Can you improve on the magic 0x18 number? What
> > about 0x8016? Is that a register whose name you know and can assign a
> > constant?
> >
>
> Register MMD7 8016 has no name in the documentation that I can see. It
> is simply referred to as that. I'd rather keep it like this rather than
> create confusion by making up a name for it.
OK
>
> -Vladimir
> ___
> 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 2/2] net: phy: Add gmiitorgmii converter support
On Thu, Jan 24, 2019 at 2:07 AM Michal Simek wrote:
>
> On 23. 01. 19 19:20, Joe Hershberger wrote:
> > On Tue, Nov 27, 2018 at 12:20 AM Siva Durga Prasad Paladugu
> > wrote:
> >>
> >> This patch adds support for gmiitorgmii converter.
> >> This converter sits between the MAC and the external phy
> >> MAC <==> GMII2RGMII <==> RGMII_PHY.
> >> The ethernet driver probes this bridge and this bridge driver
> >> probes real phy driver and invokes the real phy functionalities
> >> as requested. This bridge just needs to be configured based on
> >> real phy negotiated speed and duplex.
> >>
> >> Signed-off-by: Siva Durga Prasad Paladugu
> >> Signed-off-by: Michal Simek
> >> ---
> >
> > FYI, NI doesn't use the Xilinx adapter, we have several internal
> > adapters... GMII to RGMII, RMII, and I believe GMII (passing through
> > EMIO).
>
> ok. How do you manage them?
They are managed by 2 digital lines on EMIO
>
> >
> >> drivers/net/phy/Kconfig | 7 +++
> >> drivers/net/phy/Makefile| 1 +
> >> drivers/net/phy/phy.c | 41 ++
> >> drivers/net/phy/xilinx_gmii2rgmii.c | 103
> >>
> >> include/phy.h | 6 +++
> >> 5 files changed, 158 insertions(+)
> >> create mode 100644 drivers/net/phy/xilinx_gmii2rgmii.c
> >>
> >> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> >> index 3dc0822..a68e167 100644
> >> --- a/drivers/net/phy/Kconfig
> >> +++ b/drivers/net/phy/Kconfig
> >> @@ -217,6 +217,13 @@ config PHY_VITESSE
> >> config PHY_XILINX
> >> bool "Xilinx Ethernet PHYs support"
> >>
> >> +config PHY_XILINX_GMII2RGMII
> >> + bool "Xilinx GMII to RGMII Ethernet PHYs support"
> >> + help
> >> + This adds support for Xilinx GMII to RGMII IP core. This IP acts
> >> + as bridge between MAC connected over GMII and external phy that
> >> + is connected over RGMII interface.
> >> +
> >> config PHY_FIXED
> >> bool "Fixed-Link PHY"
> >> depends on DM_ETH
> >> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> >> index 555da83..76b6197 100644
> >> --- a/drivers/net/phy/Makefile
> >> +++ b/drivers/net/phy/Makefile
> >> @@ -27,6 +27,7 @@ obj-$(CONFIG_PHY_SMSC) += smsc.o
> >> obj-$(CONFIG_PHY_TERANETICS) += teranetics.o
> >> obj-$(CONFIG_PHY_TI) += ti.o
> >> obj-$(CONFIG_PHY_XILINX) += xilinx_phy.o
> >> +obj-$(CONFIG_PHY_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
> >> obj-$(CONFIG_PHY_VITESSE) += vitesse.o
> >> obj-$(CONFIG_PHY_MSCC) += mscc.o
> >> obj-$(CONFIG_PHY_FIXED) += fixed.o
> >> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> >> index 3cb2785..d02c4d8 100644
> >> --- a/drivers/net/phy/phy.c
> >> +++ b/drivers/net/phy/phy.c
> >> @@ -528,6 +528,9 @@ int phy_init(void)
> >> #ifdef CONFIG_PHY_FIXED
> >> phy_fixed_init();
> >> #endif
> >> +#ifdef CONFIG_PHY_XILINX_GMII2RGMII
> >> + phy_xilinx_gmii2rgmii_init();
> >> +#endif
> >
> > I'm a bit surprised this needs to act as a unique type of device and
> > not a normal phy driver? When the phy_id is read, what is returned?
> > The real phy? Nothing? You change the speed by accessing MDIO?
>
> It is connected on mdio bus but unfortunately there is no phy_id to read
> to be able to use that.
>
> https://www.xilinx.com/support/documentation/ip_documentation/gmii_to_rgmii/v4_0/pg160-gmii-to-rgmii.pdf
> page 21
That's very unfortunate. Is it not something you can have added to the IP?
> >
> >> return 0;
> >> }
> >>
> >> @@ -875,6 +878,41 @@ void phy_connect_dev(struct phy_device *phydev,
> >> struct eth_device *dev)
> >> debug("%s connected to %s\n", dev->name, phydev->drv->name);
> >> }
> >>
> >> +#ifdef CONFIG_PHY_XILINX_GMII2RGMII
> >> +#ifdef CONFIG_DM_ETH
> >> +static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus,
> >> +struct udevice *dev,
> >> +phy_interface_t interface)
> >> +#else
> >> +static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev
Re: [U-Boot] net: move ether_crc to tsec driver
Hi Chris, https://patchwork.ozlabs.org/patch/1003048/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: remove CONFIG_MCAST_TFTP
Hi Chris, https://patchwork.ozlabs.org/patch/1003050/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: realtek: Add functions to read PHY's extended registers
Hi Carlo, https://patchwork.ozlabs.org/patch/1025909/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: aquantia: Enable autoneg when on USXGMII
Hi Valentin-catalin, https://patchwork.ozlabs.org/patch/990715/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: macb: fix mapping of registers
Hi Ramon, https://patchwork.ozlabs.org/patch/1018949/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: micrel: fix KSZ9031 clock skew for values greater 0ps
Hi Andreas, https://patchwork.ozlabs.org/patch/1005603/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: remove duplicate definition of ETHADDR_WILDCARD
Hi Simon, https://patchwork.ozlabs.org/patch/1001862/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: mvneta: Add GPIO configuration support
Hi Aditya, https://patchwork.ozlabs.org/patch/1007736/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: aquantia: Print information on config
Hi Valentin-catalin, https://patchwork.ozlabs.org/patch/993651/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: mvpp2: mdio device per port
Hi Baruch, https://patchwork.ozlabs.org/patch/1001095/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: designware: fix tx packet length
Hi Simon, https://patchwork.ozlabs.org/patch/999267/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-net.git master
Hi Tom, Passed the travis build... https://travis-ci.org/jhershbe/u-boot/builds/483483372 The following changes since commit aff66f22d6eeb27c6329c0a3c1ebc52914c8affa: Merge tag 'mips-pull-2019-01-23' of git://git.denx.de/u-boot-mips (2019-01-23 17:24:31 -0500) are available in the git repository at: git://git.denx.de/u-boot-net.git master for you to fetch changes up to 91c9cbabf935b37ab6c0b9b622e7faf0b350acb6: net: phy: aquantia: Print information on config (2019-01-24 11:35:30 -0600) Aditya Prayoga (1): net: mvneta: Add GPIO configuration support Andreas Pretzsch (1): net: phy: micrel: fix KSZ9031 clock skew for values greater 0ps Baruch Siach (2): net: mvpp2: fix lookup of mdio registers base address net: mvpp2: mdio device per port Carlo Caione (1): net: phy: realtek: Add functions to read PHY's extended registers Chris Packham (3): net: mvgbe: fallback phy-mode to GMII net: move ether_crc to tsec driver net: remove CONFIG_MCAST_TFTP Pankaj Bansal (1): net: phy: Add clause 45 identifier to phy_device Ramon Fried (1): net: macb: fix mapping of registers Simon Goldschmidt (4): net: designware: fix tx packet length net: designware: clear padding bytes net: remove duplicate definition of ETHADDR_WILDCARD net: fix env flags for eth10addr and above Thomas RIENOESSL (1): net: explicitly assign errno to return code in case of network failure Valentin-catalin Neacsu (2): net: phy: aquantia: Enable autoneg when on USXGMII net: phy: aquantia: Print information on config README | 9 -- drivers/net/designware.c | 18 ++-- drivers/net/macb.c | 4 +- drivers/net/mvgbe.c | 6 +- drivers/net/mvneta.c | 15 +++ drivers/net/mvpp2.c | 84 +++ drivers/net/phy/aquantia.c | 39 +++ drivers/net/phy/micrel_ksz90x1.c | 4 +- drivers/net/phy/phy.c| 15 ++- drivers/net/phy/realtek.c| 29 ++ drivers/net/rtl8139.c| 6 +- drivers/net/tsec.c | 37 +-- drivers/usb/gadget/ether.c | 3 - include/env_callback.h | 2 - include/env_flags.h | 2 +- include/net.h| 15 +-- include/phy.h| 1 + net/eth-uclass.c | 2 - net/eth_legacy.c | 28 - net/net.c| 8 +- net/tftp.c | 219 --- scripts/config_whitelist.txt | 1 - test/dm/eth.c| 2 +- 23 files changed, 184 insertions(+), 365 deletions(-) Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: mvpp2: fix lookup of mdio registers base address
Hi Baruch, https://patchwork.ozlabs.org/patch/1001096/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: mvgbe: fallback phy-mode to GMII
Hi Chris, https://patchwork.ozlabs.org/patch/1007466/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: Add clause 45 identifier to phy_device
Hi Pankaj, https://patchwork.ozlabs.org/patch/998770/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: fix env flags for eth10addr and above
Hi Simon, https://patchwork.ozlabs.org/patch/1001866/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: explicitly assign errno to return code in case of network failure
Hi Thomas, https://patchwork.ozlabs.org/patch/1001188/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: designware: clear padding bytes
Hi Simon, https://patchwork.ozlabs.org/patch/999268/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] net: phy: ar803x: Use phy_read_mmd and phy_write_mmd functions
On Wed, Jan 23, 2019 at 5:46 PM Vladimir Oltean wrote:
>
> Signed-off-by: Vladimir Oltean
> ---
> Changes in v2:
> * Patch added in this version.
>
> drivers/net/phy/atheros.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
> index 3783d15..b4066e3 100644
> --- a/drivers/net/phy/atheros.c
> +++ b/drivers/net/phy/atheros.c
> @@ -57,11 +57,9 @@ static int ar8035_config(struct phy_device *phydev)
> {
> int regval;
>
> - phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x0007);
> - phy_write(phydev, MDIO_DEVAD_NONE, 0xe, 0x8016);
> - phy_write(phydev, MDIO_DEVAD_NONE, 0xd, 0x4007);
> - regval = phy_read(phydev, MDIO_DEVAD_NONE, 0xe);
> - phy_write(phydev, MDIO_DEVAD_NONE, 0xe, (regval|0x0018));
> + /* CLK_25M output clock select: 125 MHz */
> + regval = phy_read_mmd(phydev, MDIO_MMD_AN, 0x8016);
> + phy_write_mmd(phydev, MDIO_MMD_AN, 0x8016, regval | 0x0018);
I think I see how the old code accomplished the same thing. It was
woefully undocumented. Can you improve on the magic 0x18 number? What
about 0x8016? Is that a register whose name you know and can assign a
constant?
>
> phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
> regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);
> --
> 2.7.4
>
> ___
> 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 v2 2/3] net: phy: ar803x: Address packet drops at low traffic rate due to SmartEEE feature
On Wed, Jan 23, 2019 at 5:45 PM Vladimir Oltean wrote:
>
> * According to the AR8031 and AR8035 datasheets, smartEEE mode
> (active by default) makes the PHY enter sleep after a configurable
> idle time. It does this autonomously, without LPI (Low Power Idle)
> signals coming from MAC. AR8021 does not appear to support this.
> * This patch allows disabling the SmartEEE feature of above PHYs.
> * Tested with ping (default of 1 second interval) over back-to-back
> RGMII between 2 boards having AR8035 at both ends:
> - Without SmartEEE:
> 225 packets transmitted, 145 received, 35% packet loss, time 229334ms
> - With SmartEEE:
> 144 packets transmitted, 144 received, 0% packet loss, time 146378ms
>
> Signed-off-by: Vladimir Oltean
> Acked-by: Joe Hershberger
> ---
> Changes in v2:
> * Adapted to use phy_read_mmd and phy_write_mmd functions.
>
> drivers/net/phy/Kconfig | 21 +
> drivers/net/phy/atheros.c | 26 ++
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 3dc0822..6abe8c5 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -94,6 +94,27 @@ config PHY_AQUANTIA_FW_NAME
> config PHY_ATHEROS
> bool "Atheros Ethernet PHYs support"
>
> +config PHY_ATHEROS_SMART_EEE
> + depends on PHY_ATHEROS
> + default y
> + tristate "SmartEEE feature for Atheros PHYs"
> + help
> + Enables the Atheros SmartEEE feature (not IEEE 802.3az). When 2 PHYs
> + which support this feature are connected back-to-back, they may
> + negotiate a low-power sleep mode autonomously, without the Ethernet
> + controller's knowledge. This setting may cause issues under 2 known
> + circumstances (both noticed at low traffic rates):
> + - If the voltage rails on the PHY are unstable, then the PHY can
> + actually reset as it enters the low power state. This means that
> + the frames it is supposed to buffer until it wakes up are going
> + to be dropped instead.
> + - If 1588/PTP synchronization is the only traffic source over this
> + PHY, the delays caused by the sleep/wakeup time are going to add
> + to the synchronization error between the master and the slave.
> + Default y, which means that the PHY's out-of-reset state is not
> + changed (SmartEEE active). To work around the issues described
> + above, change to n.
> +
> config PHY_BROADCOM
> bool "Broadcom Ethernet PHYs support"
>
> diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
> index b4066e3..750c11b 100644
> --- a/drivers/net/phy/atheros.c
> +++ b/drivers/net/phy/atheros.c
> @@ -5,6 +5,7 @@
> * Copyright 2011, 2013 Freescale Semiconductor, Inc.
> * author Andy Fleming
> */
> +#include
> #include
> #include
>
> @@ -17,6 +18,21 @@
> #define AR803x_DEBUG_REG_0 0x0
> #define AR803x_RGMII_RX_CLK_DLY0x8000
>
> +#define AR803X_LPI_EN BIT(8)
> +
> +static void ar803x_enable_smart_eee(struct phy_device *phydev, bool on)
> +{
> + int regval;
> +
> + /* 5.1.11 Smart_eee control3 */
> + regval = phy_read_mmd(phydev, MDIO_MMD_PCS, 0x805D);
Can you add a #define for this or comment where it comes from / what
it means in a data sheet or both?
> + if (on)
> + regval |= AR803X_LPI_EN;
> + else
> + regval &= ~AR803X_LPI_EN;
> + phy_write_mmd(phydev, MDIO_MMD_PCS, 0x805D, regval);
> +}
> +
> static int ar8021_config(struct phy_device *phydev)
> {
> phy_write(phydev, MDIO_DEVAD_NONE, 0x00, 0x1200);
> @@ -29,6 +45,11 @@ static int ar8021_config(struct phy_device *phydev)
>
> static int ar8031_config(struct phy_device *phydev)
> {
> +#ifdef CONFIG_PHY_ATHEROS_SMART_EEE
> + ar803x_enable_smart_eee(phydev, true);
> +#else
> + ar803x_enable_smart_eee(phydev, false);
> +#endif
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
> phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
> phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG,
> @@ -57,6 +78,11 @@ static int ar8035_config(struct phy_device *phydev)
> {
> int regval;
>
> +#ifdef CONFIG_PHY_ATHEROS_SMART_EEE
> + ar803x_enable_smart_eee(phydev, true);
> +#else
> + ar803x_enable_smart_eee(phydev, false);
> +#endif
> /* CLK_25M output clock select: 125 MHz */
> regval = phy_read_mmd(phydev, MDIO_MMD_AN, 0x8016);
> phy_write_mmd(phydev, MDIO_MMD_AN, 0x8016, regval | 0x0018);
> --
> 2.7.4
>
> ___
> 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 v2 3/3] net: phy: ar803x: Use common functions for RGMII internal delays
On Wed, Jan 23, 2019 at 5:47 PM Vladimir Oltean wrote:
>
> Signed-off-by: Vladimir Oltean
> ---
> Changes in v2:
> * Patch added in this version.
>
> drivers/net/phy/atheros.c | 76
> ---
> 1 file changed, 45 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/net/phy/atheros.c b/drivers/net/phy/atheros.c
> index 750c11b..9eb40f7 100644
> --- a/drivers/net/phy/atheros.c
> +++ b/drivers/net/phy/atheros.c
> @@ -13,10 +13,10 @@
> #define AR803x_PHY_DEBUG_DATA_REG 0x1e
>
> #define AR803x_DEBUG_REG_5 0x5
> -#define AR803x_RGMII_TX_CLK_DLY0x100
> +#define AR803x_RGMII_TX_CLK_DLYBIT(8)
>
> #define AR803x_DEBUG_REG_0 0x0
> -#define AR803x_RGMII_RX_CLK_DLY0x8000
> +#define AR803x_RGMII_RX_CLK_DLYBIT(15)
>
> #define AR803X_LPI_EN BIT(8)
>
> @@ -33,11 +33,40 @@ static void ar803x_enable_smart_eee(struct phy_device
> *phydev, bool on)
> phy_write_mmd(phydev, MDIO_MMD_PCS, 0x805D, regval);
> }
>
> +static void ar803x_enable_rx_delay(struct phy_device *phydev, bool on)
> +{
> + int regval;
> +
> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG,
> + AR803x_DEBUG_REG_0);
> + regval = phy_read(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG);
> + if (on)
> + regval |= AR803x_RGMII_RX_CLK_DLY;
> + else
> + regval &= ~AR803x_RGMII_RX_CLK_DLY;
> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG, regval);
> +}
> +
> +static void ar803x_enable_tx_delay(struct phy_device *phydev, bool on)
> +{
> + int regval;
> +
> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG,
> + AR803x_DEBUG_REG_5);
> + regval = phy_read(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG);
> + if (on)
> + regval |= AR803x_RGMII_TX_CLK_DLY;
> + else
> + regval &= ~AR803x_RGMII_TX_CLK_DLY;
> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG, regval);
> +}
> +
> static int ar8021_config(struct phy_device *phydev)
> {
> phy_write(phydev, MDIO_DEVAD_NONE, 0x00, 0x1200);
> - phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
> - phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x3D47);
> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG,
> + AR803x_DEBUG_REG_5);
> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG, 0x3D47);
While this patch is an improvement on the former state, can we add a
comment on the magic number or define a constant?
>
> phydev->supported = phydev->drv->features;
> return 0;
> @@ -51,20 +80,12 @@ static int ar8031_config(struct phy_device *phydev)
> ar803x_enable_smart_eee(phydev, false);
> #endif
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID ||
> - phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
> - phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG,
> - AR803x_DEBUG_REG_5);
> - phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG,
> - AR803x_RGMII_TX_CLK_DLY);
> - }
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
> + ar803x_enable_tx_delay(phydev, true);
>
> if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID ||
> - phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
> - phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG,
> - AR803x_DEBUG_REG_0);
> - phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG,
> - AR803x_RGMII_RX_CLK_DLY);
> - }
> + phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
> + ar803x_enable_rx_delay(phydev, true);
>
> phydev->supported = phydev->drv->features;
>
> @@ -87,25 +108,18 @@ static int ar8035_config(struct phy_device *phydev)
> regval = phy_read_mmd(phydev, MDIO_MMD_AN, 0x8016);
> phy_write_mmd(phydev, MDIO_MMD_AN, 0x8016, regval | 0x0018);
>
> - phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
> - regval = phy_read(phydev, MDIO_DEVAD_NONE, 0x1e);
> - phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, (regval|0x0100));
> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_ADDR_REG, 0x05);
What is 0x5?
> + regval = phy_read(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG);
> + phy_write(phydev, MDIO_DEVAD_NONE, AR803x_PHY_DEBUG_DATA_REG,
> + regval | 0x0100);
What is 0x100?
>
> if ((phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) ||
> - (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
> - /* select debug reg 5 */
> - phy_write(phydev, MDIO_DEVAD_NONE, 0x1D, 0x5);
> - /* enable tx delay */
>
Re: [U-Boot] [PATCH 1/2] net: phy: Move fixed link code to separate routine
On Tue, Nov 27, 2018 at 12:20 AM Siva Durga Prasad Paladugu wrote: > > This patch moves fixed-link functionality code to a separate > routine inorder to make it more modular and cleaner. > > Signed-off-by: Siva Durga Prasad Paladugu > Signed-off-by: Michal Simek 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: phy: Add gmiitorgmii converter support
On Tue, Nov 27, 2018 at 12:20 AM Siva Durga Prasad Paladugu
wrote:
>
> This patch adds support for gmiitorgmii converter.
> This converter sits between the MAC and the external phy
> MAC <==> GMII2RGMII <==> RGMII_PHY.
> The ethernet driver probes this bridge and this bridge driver
> probes real phy driver and invokes the real phy functionalities
> as requested. This bridge just needs to be configured based on
> real phy negotiated speed and duplex.
>
> Signed-off-by: Siva Durga Prasad Paladugu
> Signed-off-by: Michal Simek
> ---
FYI, NI doesn't use the Xilinx adapter, we have several internal
adapters... GMII to RGMII, RMII, and I believe GMII (passing through
EMIO).
> drivers/net/phy/Kconfig | 7 +++
> drivers/net/phy/Makefile| 1 +
> drivers/net/phy/phy.c | 41 ++
> drivers/net/phy/xilinx_gmii2rgmii.c | 103
>
> include/phy.h | 6 +++
> 5 files changed, 158 insertions(+)
> create mode 100644 drivers/net/phy/xilinx_gmii2rgmii.c
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 3dc0822..a68e167 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -217,6 +217,13 @@ config PHY_VITESSE
> config PHY_XILINX
> bool "Xilinx Ethernet PHYs support"
>
> +config PHY_XILINX_GMII2RGMII
> + bool "Xilinx GMII to RGMII Ethernet PHYs support"
> + help
> + This adds support for Xilinx GMII to RGMII IP core. This IP acts
> + as bridge between MAC connected over GMII and external phy that
> + is connected over RGMII interface.
> +
> config PHY_FIXED
> bool "Fixed-Link PHY"
> depends on DM_ETH
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index 555da83..76b6197 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_PHY_SMSC) += smsc.o
> obj-$(CONFIG_PHY_TERANETICS) += teranetics.o
> obj-$(CONFIG_PHY_TI) += ti.o
> obj-$(CONFIG_PHY_XILINX) += xilinx_phy.o
> +obj-$(CONFIG_PHY_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
> obj-$(CONFIG_PHY_VITESSE) += vitesse.o
> obj-$(CONFIG_PHY_MSCC) += mscc.o
> obj-$(CONFIG_PHY_FIXED) += fixed.o
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 3cb2785..d02c4d8 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -528,6 +528,9 @@ int phy_init(void)
> #ifdef CONFIG_PHY_FIXED
> phy_fixed_init();
> #endif
> +#ifdef CONFIG_PHY_XILINX_GMII2RGMII
> + phy_xilinx_gmii2rgmii_init();
> +#endif
I'm a bit surprised this needs to act as a unique type of device and
not a normal phy driver? When the phy_id is read, what is returned?
The real phy? Nothing? You change the speed by accessing MDIO?
> return 0;
> }
>
> @@ -875,6 +878,41 @@ void phy_connect_dev(struct phy_device *phydev, struct
> eth_device *dev)
> debug("%s connected to %s\n", dev->name, phydev->drv->name);
> }
>
> +#ifdef CONFIG_PHY_XILINX_GMII2RGMII
> +#ifdef CONFIG_DM_ETH
> +static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus,
> +struct udevice *dev,
> +phy_interface_t interface)
> +#else
> +static struct phy_device *phy_connect_gmii2rgmii(struct mii_dev *bus,
> +struct eth_device *dev,
> +phy_interface_t interface)
> +#endif
> +{
> + struct phy_device *phydev = NULL;
> + int sn = dev_of_offset(dev);
> + int off;
> +
> + while (sn > 0) {
> + off = fdt_node_offset_by_compatible(gd->fdt_blob, sn,
> + "xlnx,gmii-to-rgmii-1.0");
This seems to be searching under the eth dev, but at least in the
"linux/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt"
docs, this is found under the mdio node. How is this supposed to
handle more than one bridge?
> + if (off > 0) {
> + phydev = phy_device_create(bus,
> + off, PHY_GMII2RGMII_ID,
> + interface);
> + break;
> + }
> + if (off == -FDT_ERR_NOTFOUND)
> + sn = fdt_first_subnode(gd->fdt_blob, sn);
> + else
> + printf("%s: Error finding compat string:%d\n",
> + __func__, off);
> + }
> +
> + return phydev;
> +}
> +#endif
> +
> #ifdef CONFIG_PHY_FIXED
> #ifdef CONFIG_DM_ETH
> static struct phy_device *phy_connect_fixed(struct mii_dev *bus,
> @@ -920,6 +958,9 @@ struct phy_device *phy_connect(struct mii_dev *bus, int
> addr,
> #ifdef CONFIG_PHY_FIXED
> phydev = phy_connect_fixed(bus, dev, interface);
> #endif
> +#ifdef CONFIG_PHY_XILINX_GMII
Re: [U-Boot] [PATCH] net: phy: realtek: Introduce quirk to mark RXC not stoppable
On Wed, Jan 23, 2019 at 10:39 AM Carlo Caione wrote: > > On 23/01/19 16:19, Joe Hershberger wrote: > > /cut > >> + transitions to/from a lower power consumption level (Low > >> Power Idle > >> + mode) based on link utilization. When no packets are being > >> + transmitted, the system goes to Low Power Idle mode to save > >> power. > >> + > >> + Under particular circumstances this setting can cause issues > >> where > >> + the PHY is unable to transmit or receive any packet when in LPI > >> mode. > >> + The problem is caused when the PHY is configured to stop > >> receiving > >> + the xMII clock while it is signaling LPI. When not stated > >> otherwise > >> + this bit is set by libphy in the linux kernel. > > > >This seems to be copied from Linux, please update to describe what > >happens in U-Boot. > > It is not copied from Linux. The problem is that the libphy in the > kernel is flipping this bit and this is causing the issue in U-Boot on > reboot. So I'm saying exactly that. I see... you are saying it retains the value that may have be changed by Linux. "When not stated otherwise" is to mean "If this config is disabled" Should capitalize Linux. > > -- > Carlo Caione > ___ > 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 v3 3/3] cmd: mdio: Add new parameter to access MMD PHY registers
On Wed, Jan 23, 2019 at 10:58 AM Carlo Caione wrote: > > On 23/01/19 16:31, Joe Hershberger wrote: > >On Wed, Jan 23, 2019 at 10:23 AM Joe Hershberger > >wrote: > >> > >> On Wed, Jan 23, 2019 at 10:07 AM Carlo Caione wrote: > >> > > >> > Two new parameters (rmmd and wmmd) are added to allow the `mdio` command > >> > to access the content of the MMD PHY registers. > >> > > >> > Signed-off-by: Carlo Caione > >> > >> Acked-by: Joe Hershberger > > > >checkpatch.pl failures... please address. > > Uhm, ok for the line over 80 characters but the quoted string split > across lines warning is really there for consistency with the old code. OK, if it was pre-existing and it doesn't make sense to change, that's ok. > > -- > Carlo Caione > ___ > 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 v3 3/3] cmd: mdio: Add new parameter to access MMD PHY registers
On Wed, Jan 23, 2019 at 10:23 AM Joe Hershberger wrote: > > On Wed, Jan 23, 2019 at 10:07 AM Carlo Caione wrote: > > > > Two new parameters (rmmd and wmmd) are added to allow the `mdio` command > > to access the content of the MMD PHY registers. > > > > Signed-off-by: Carlo Caione > > Acked-by: Joe Hershberger checkpatch.pl failures... please address. > ___ > 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 v3 1/3] net: phy: Add support for accessing MMD PHY registers
On Wed, Jan 23, 2019 at 10:21 AM Joe Hershberger wrote: > > On Wed, Jan 23, 2019 at 10:07 AM Carlo Caione wrote: > > > > Two new helper functions (phy_read_mmd() and phy_write_mmd()) are added > > to allow access to the MMD PHY registers. > > > > The MMD PHY registers can be accessed by two means: > > > > 1. Using two new MMD access function hooks in the PHY driver. These > > functions can be implemented when the PHY driver does not support the > > standard IEEE Compatible clause 45 access mechanism described in clause > > 22 or if the PHY uses its own non-standard access mechanism. > > > > 2. The standard clause 45 access extensions to the MMD registers through > > the indirection registers (clause 22) in all the other cases. > > > > Signed-off-by: Carlo Caione > > Acked-by: Joe Hershberger checkpatch.pl failures... please address. > ___ > 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 v3 3/3] cmd: mdio: Add new parameter to access MMD PHY registers
On Wed, Jan 23, 2019 at 10:07 AM Carlo Caione wrote: > > Two new parameters (rmmd and wmmd) are added to allow the `mdio` command > to access the content of the MMD PHY registers. > > Signed-off-by: Carlo Caione 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 1/3] net: phy: Add support for accessing MMD PHY registers
On Wed, Jan 23, 2019 at 10:07 AM Carlo Caione wrote: > > Two new helper functions (phy_read_mmd() and phy_write_mmd()) are added > to allow access to the MMD PHY registers. > > The MMD PHY registers can be accessed by two means: > > 1. Using two new MMD access function hooks in the PHY driver. These > functions can be implemented when the PHY driver does not support the > standard IEEE Compatible clause 45 access mechanism described in clause > 22 or if the PHY uses its own non-standard access mechanism. > > 2. The standard clause 45 access extensions to the MMD registers through > the indirection registers (clause 22) in all the other cases. > > Signed-off-by: Carlo Caione 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: realtek: Introduce quirk to mark RXC not stoppable
On Wed, Jan 23, 2019 at 7:57 AM Carlo Caione wrote:
>
> When EEE is supported by the PHY and the driver allows it, libphy in the
> kernel is configuring the PHY to stop receiving the xMII clock while it
> is signaling LPI. While this (usually) works fine in the kernel this is
> causing issues in U-Boot when rebooting from the linux kernel with this
> bit set (without having the possibility to reset the PHY) where the PHY
> suddenly stops working.
>
> A new quirk is introduced to unconditionally reset this bit. If the
> quirk is not enabled using the proper configuration symbol, the PHY state
> is not changed.
>
> Signed-off-by: Carlo Caione
Other than a few nits below,
Acked-by: Joe Hershberger
> ---
>
> Hi Joe,
> just an heads up that this patch depends on the MMD helpers patch I
> submitted earlier.
>
> ---
> drivers/net/phy/Kconfig | 19 +++
> drivers/net/phy/realtek.c | 19 +++
> 2 files changed, 38 insertions(+)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 3dc0822d9c..d0dab3014e 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -202,6 +202,25 @@ config RTL8211X_PHY_FORCE_MASTER
>
> If unsure, say N.
>
> +config RTL8211F_PHY_FORCE_EEE_RXC_ON
> + bool "Ethernet PHY RTL8211F: do not stop receiving the xMII clock
> during LPI"
> + depends on PHY_REALTEK
> + default n
> + help
> + The IEEE 802.3az-2010 (EEE) standar provides a protocol to
> coordinate
Typo: standard
> + transitions to/from a lower power consumption level (Low Power Idle
> + mode) based on link utilization. When no packets are being
> + transmitted, the system goes to Low Power Idle mode to save power.
> +
> + Under particular circumstances this setting can cause issues where
> + the PHY is unable to transmit or receive any packet when in LPI
> mode.
> + The problem is caused when the PHY is configured to stop receiving
> + the xMII clock while it is signaling LPI. When not stated otherwise
> + this bit is set by libphy in the linux kernel.
This seems to be copied from Linux, please update to describe what
happens in U-Boot.
> +
> + Default n, which means that the PHY state is not changed. To work
> + around the issues, change this setting to y.
> +
> config PHY_SMSC
> bool "Microchip(SMSC) Ethernet PHYs support"
>
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index b3e6578df9..fa11696fe2 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -12,6 +12,7 @@
>
> #define PHY_RTL8211x_FORCE_MASTER BIT(1)
> #define PHY_RTL8211E_PINE64_GIGABIT_FIX BIT(2)
> +#define PHY_RTL8211F_FORCE_EEE_RXC_ON BIT(3)
>
> #define PHY_AUTONEGOTIATE_TIMEOUT 5000
>
> @@ -75,6 +76,15 @@ static int rtl8211e_probe(struct phy_device *phydev)
> return 0;
> }
>
> +static int rtl8211f_probe(struct phy_device *phydev)
> +{
> +#ifdef CONFIG_RTL8211F_PHY_FORCE_EEE_RXC_ON
> + phydev->flags |= PHY_RTL8211F_FORCE_EEE_RXC_ON;
> +#endif
> +
> + return 0;
> +}
> +
> /* RealTek RTL8211x */
> static int rtl8211x_config(struct phy_device *phydev)
> {
> @@ -124,6 +134,14 @@ static int rtl8211f_config(struct phy_device *phydev)
> {
> u16 reg;
>
> + if (phydev->flags & PHY_RTL8211F_FORCE_EEE_RXC_ON) {
> + unsigned int reg;
> +
> + reg = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_CTRL1);
> + reg &= ~MDIO_PCS_CTRL1_CLKSTOP_EN;
> + phy_write_mmd(phydev, MDIO_MMD_PCS, MDIO_CTRL1, reg);
> + }
> +
> phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
>
> phy_write(phydev, MDIO_DEVAD_NONE,
> @@ -333,6 +351,7 @@ static struct phy_driver RTL8211F_driver = {
> .uid = 0x1cc916,
> .mask = 0xff,
> .features = PHY_GBIT_FEATURES,
> + .probe = &rtl8211f_probe,
> .config = &rtl8211f_config,
> .startup = &rtl8211f_startup,
> .shutdown = &genphy_shutdown,
> --
> 2.19.1
>
> ___
> 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 u-boot 1/2] net: phy: Add support for accessing MMD PHY registers
On Wed, Jan 23, 2019 at 8:32 AM Vladimir Oltean wrote: > > On 23.01.2019 11:59, Carlo Caione wrote: > > On 23/01/19 00:04, Joe Hershberger wrote: > >> > >> If we have to override the access then probably so. Maybe it would > >> make more sense to have a v2 from you that removes the duplicate code > >> from the ti phy driver and then have Vlad's smartEEE patch be rebased > >> on that. > >> > >> I have not yet pushed Vlad's patches so we have an opportunity to do > >> it more cleanly potentially. > >> > >> Thoughts from each of you? > > > > I'll rebase that patch on top of my set and I'll let Vlad submit the > > smartEEE patch on top. > > > > Hi Carlo, good if you could take care of the TI driver and I will resend > the Atheros SmartEEE patch to use phy_read_mmd/phy_write_mmd. He's already sent a V1 that you could base off of. The changes I requested should not make it incompatible with your Atheros change. Thanks, -Joe > > Thanks, > -Vladimir > ___ > 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 v2 2/3] net: phy: ti: use generic helpers to access MMD registers
On Wed, Jan 23, 2019 at 7:15 AM Carlo Caione wrote: > > Now that generic helpers are available, use those instead of relying on > ti specific functions. > > Signed-off-by: Carlo Caione > Signed-off-by: Vladimir Oltean 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/3] net: phy: Add support for accessing MMD PHY registers
On Wed, Jan 23, 2019 at 7:14 AM Carlo Caione wrote:
>
> Two new helper functions (phy_read_mmd() and phy_write_mmd()) are added
> to allow access to the MMD PHY registers.
>
> The MMD PHY registers can be accessed by two means:
>
> 1. Using two new MMD access function hooks in the PHY driver. These
> functions can be implemented when the PHY driver does not support the
> standard IEEE Compatible clause 45 access mechanism described in clause
> 22 or if the PHY uses its own non-standard access mechanism.
>
> 2. The standard clause 45 access extensions to the MMD registers through
> the indirection registers (clause 22) in all the other cases.
>
> Signed-off-by: Carlo Caione
> ---
> drivers/net/phy/phy.c | 4 +++
> include/phy.h | 62 +++
> 2 files changed, 66 insertions(+)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index cda4caa803..6769047407 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -549,6 +549,10 @@ int phy_register(struct phy_driver *drv)
> drv->readext += gd->reloc_off;
> if (drv->writeext)
> drv->writeext += gd->reloc_off;
> + if (drv->read_mmd)
> + drv->read_mmd += gd->reloc_off;
> + if (drv->write_mmd)
> + drv->write_mmd += gd->reloc_off;
> #endif
> return 0;
> }
> diff --git a/include/phy.h b/include/phy.h
> index b86fdfb2ce..0ce41661fa 100644
> --- a/include/phy.h
> +++ b/include/phy.h
> @@ -101,6 +101,13 @@ struct phy_driver {
> int (*readext)(struct phy_device *phydev, int addr, int devad, int
> reg);
> int (*writeext)(struct phy_device *phydev, int addr, int devad, int
> reg,
> u16 val);
> +
> + /* Phy specific driver override for reading a MMD register */
> + int (*read_mmd)(struct phy_device *phydev, int devad, int reg);
> +
> + /* Phy specific driver override for writing a MMD register */
> + int (*write_mmd)(struct phy_device *phydev, int devad, int reg, u16
> val);
> +
> struct list_head list;
> };
>
> @@ -164,6 +171,61 @@ static inline int phy_write(struct phy_device *phydev,
> int devad, int regnum,
> return bus->write(bus, phydev->addr, devad, regnum, val);
> }
>
> +static inline void phy_mmd_indirect(struct phy_device *phydev, int devad,
> + int regnum)
> +{
> + /* Write the desired MMD Devad */
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_MMD_CTRL, devad);
> +
> + /* Write the desired MMD register address */
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_MMD_DATA, regnum);
> +
> + /* Select the Function : DATA with no post increment */
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_MMD_CTRL, (devad |
> MII_MMD_CTRL_NOINCR));
> +}
> +
> +static inline int phy_read_mmd(struct phy_device *phydev, int devad,
> + int regnum)
> +{
> + int ret;
> +
> + if (regnum > (u16)~0 || devad > 32)
> + return -EINVAL;
> +
> + if (phydev->drv->read_mmd) {
> + ret = phydev->drv->read_mmd(phydev, devad, regnum);
> + } else {
> + phy_mmd_indirect(phydev, devad, regnum);
I think this function should have a name that more clearly conveys
that it doesn't actually complete an indirect access.
Maybe phy_mmd_start_indirect() ?
> +
> + /* Read the content of the MMD's selected register */
> + ret = phy_read(phydev, MDIO_DEVAD_NONE, MII_MMD_DATA);
> + }
> +
> + return ret;
You shouldn't need this variable... just return from the 2 sites that
return errors.
> +}
> +
> +static inline int phy_write_mmd(struct phy_device *phydev, int devad,
> + int regnum, u16 val)
> +{
> + int ret;
> +
> + if (regnum > (u16)~0 || devad > 32)
> + return -EINVAL;
> +
> + if (phydev->drv->write_mmd) {
> + ret = phydev->drv->write_mmd(phydev, devad, regnum, val);
You could simply return from here.
> + } else {
> + phy_mmd_indirect(phydev, devad, regnum);
> +
> + /* Write the data into MMD's selected register */
> + phy_write(phydev, MDIO_DEVAD_NONE, MII_MMD_DATA, val);
> +
> + ret = 0;
You should return any error from phy_write above and get rid of the
ret variable.
> + }
> +
> + return ret;
> +}
> +
> #ifdef CONFIG_PHYLIB_10G
> extern struct phy_driver gen10g_driver;
>
> --
> 2.19.1
>
> ___
> 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 v2 3/3] cmd: mdio: Add new parameter to access MMD PHY registers
On Wed, Jan 23, 2019 at 7:15 AM Carlo Caione wrote:
>
> Two new parameters (rmmd and wmmd) are added to allow the `mdio` command
> to access the content of the MMD PHY registers.
>
> Signed-off-by: Carlo Caione
> ---
> cmd/mdio.c | 33 +++--
> 1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/cmd/mdio.c b/cmd/mdio.c
> index 184868063a..010632b562 100644
> --- a/cmd/mdio.c
> +++ b/cmd/mdio.c
> @@ -43,7 +43,7 @@ static int mdio_write_ranges(struct phy_device *phydev,
> struct mii_dev *bus,
> int addrlo,
> int addrhi, int devadlo, int devadhi,
> int reglo, int reghi, unsigned short data,
> -int extended)
> +int extended, int mmd)
> {
> int addr, devad, reg;
> int err = 0;
> @@ -51,7 +51,9 @@ static int mdio_write_ranges(struct phy_device *phydev,
> struct mii_dev *bus,
> for (addr = addrlo; addr <= addrhi; addr++) {
> for (devad = devadlo; devad <= devadhi; devad++) {
> for (reg = reglo; reg <= reghi; reg++) {
> - if (!extended)
> + if (mmd)
> + err = phy_write_mmd(phydev, devad,
> reg, data);
> + else if (!extended)
Please don't keep the negative logic and switch these last two.
> err = bus->write(bus, addr, devad,
> reg, data);
> else
> @@ -71,7 +73,7 @@ err_out:
> static int mdio_read_ranges(struct phy_device *phydev, struct mii_dev *bus,
> int addrlo,
> int addrhi, int devadlo, int devadhi,
> - int reglo, int reghi, int extended)
> + int reglo, int reghi, int extended, int mmd)
> {
> int addr, devad, reg;
>
> @@ -83,7 +85,9 @@ static int mdio_read_ranges(struct phy_device *phydev,
> struct mii_dev *bus,
> for (reg = reglo; reg <= reghi; reg++) {
> int val;
>
> - if (!extended)
> + if (mmd)
> + val = phy_read_mmd(phydev, devad,
> reg);
> + else if (!extended)
Please don't keep the negative logic and switch these last two.
> val = bus->read(bus, addr, devad,
> reg);
> else
> val = phydev->drv->readext(phydev,
> addr,
> @@ -189,6 +193,7 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> struct mii_dev *bus;
> struct phy_device *phydev = NULL;
> int extended = 0;
> + int mmd = 0;
>
> if (argc < 2)
> return CMD_RET_USAGE;
> @@ -232,6 +237,18 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> return -1;
> }
> }
> + if (op[1] == 'm') {
> + phydev = mdio_phydev_for_ethname(argv[2]);
> +
> + if (phydev) {
> + addrlo = phydev->addr;
> + addrhi = addrlo;
> + bus = phydev->bus;
> + mmd = 1;
> + } else {
> + return -1;
Please use a valid command response macro. CMD_RET_FAILURE in this
case. Feel free to fix it in the other places in this command as well.
> + }
> + }
> }
>
> switch (op[0]) {
> @@ -265,12 +282,12 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> switch (op[0]) {
> case 'w':
> mdio_write_ranges(phydev, bus, addrlo, addrhi, devadlo,
> devadhi,
> - reglo, reghi, data, extended);
> + reglo, reghi, data, extended, mmd);
> break;
>
> case 'r':
> mdio_read_ranges(phydev, bus, addrlo, addrhi, devadlo,
> devadhi,
> -reglo, reghi, extended);
> +reglo, reghi, extended, mmd);
> break;
> }
>
> @@ -303,6 +320,10 @@ U_BOOT_CMD(
> "read PHY's extended register at .\n"
> "mdio wx [.] - "
> "write PHY's extended register at .\n"
> + "mdio rmmd [.] - "
> + "read PHY's extended register at .\n"
> + "mdio wmmd [.] - "
> + "write PHY's extended register at .\n"
> " may be:\n"
> "
Re: [U-Boot] [PATCH v3 04/12] net: macb: Fix clk API usage for RISC-V systems
On Tue, Jan 22, 2019 at 10:31 PM Anup Patel wrote: > > This patch does following fixes in MACB ethernet driver > for using it on RISC-V systems (particularly QEMU sifive_u > machine): > 1. asm/arch/clk.h is not available on RISC-V port so include >it only for non-RISC-V systems. > 2. Don't fail in macb_enable_clk() if clk_enable() returns >-ENOSYS because we get -ENOSYS for fixed-rate clocks. > > Signed-off-by: Anup Patel > Reviewed-by: Bin Meng > --- > drivers/net/macb.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/macb.c b/drivers/net/macb.c > index 94c89c762b..9a06b523cc 100644 > --- a/drivers/net/macb.c > +++ b/drivers/net/macb.c > @@ -38,7 +38,9 @@ > #include > #include > #include > +#ifndef CONFIG_RISCV > #include It seems much better to include an empty header than to ifdef here. > +#endif > #include > > #include "macb.h" > @@ -1066,7 +1068,7 @@ static int macb_enable_clk(struct udevice *dev) > */ > #ifndef CONFIG_MACB_ZYNQ > ret = clk_enable(&clk); > - if (ret) > + if (ret && ret != -ENOSYS) > return ret; > #endif > > -- > 2.17.1 > > ___ > 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 v3 05/12] net: macb: Fix GEM hardware detection
On Tue, Jan 22, 2019 at 10:30 PM Anup Patel wrote: > > From: Atish Patra > > Fix MID bit field check to correctly identify all GEM hardwares. > > The check is updated as per macb driver in Linux location: > /drivers/net/ethernet/cadence/macb_main.c:259 > > Signed-off-by: Atish Patra > Signed-off-by: Anup Patel > Reviewed-by: Alexander Graf > Reviewed-by: Lukas Auer Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 1/2] net: phy: Add support for accessing MMD PHY registers
On Tue, Jan 22, 2019 at 4:54 PM Carlo Caione wrote: > > On 22/01/19 22:21, Joe Hershberger wrote: > >On Wed, Jan 16, 2019 at 12:06 PM Carlo Caione wrote: > >> > >> Two new helper functions (phy_read_mmd() and phy_write_mmd()) are added > >> to allow access to the MMD PHY registers. > >> > >> The MMD PHY registers can be accessed by two means: > >> > >> 1. Using two new MMD access function hooks in the PHY driver. These > >> functions can be implemented when the PHY driver does not support the > >> standard IEEE Compatible clause 45 access mechanism described in clause > >> 22 or if the PHY uses its own non-standard access mechanism. > >> > >> 2. The standard clause 45 access extensions to the MMD registers through > >> the indirection registers (clause 22) in all the other cases. > >> > >> Signed-off-by: Carlo Caione > > > >This seems like a duplicate of https://patchwork.ozlabs.org/patch/1015782/ > > Well, I should have looked better. Interestingly I was going to use my > patch to fix the exact same issue on a different PHY. > > The problem I see with that patch is that it is assuming that all the > PHY devices support clause 45 access extension using the clause 22 > registers. This is not always true (see for example [0]). That's why I > added two new hooks in the PHY driver. Ah, I didn't realize there were other ways to access it. > On a side note looking at that patch it seems that 'addr' (documented as > the PHY address in the same patch) is being passed to 'phy_write' where > we should have the 'devad' parameter instead (MDIO_DEVAD_NONE)? That is peculiar... Vlad, that wasn't your intent, was it? > >The command patch should probably be adapted to use that. > > Let me know if you think it is valuable still to add the two hooks on > top of that patch. If we have to override the access then probably so. Maybe it would make more sense to have a v2 from you that removes the duplicate code from the ti phy driver and then have Vlad's smartEEE patch be rebased on that. I have not yet pushed Vlad's patches so we have an opportunity to do it more cleanly potentially. Thoughts from each of you? > Thanks, > > [0] https://patchwork.ozlabs.org/patch/351634/ > > -- > Carlo Caione > ___ > 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 2/2] net: remove CONFIG_MCAST_TFTP
On Mon, Nov 26, 2018 at 11:59 PM Simon Goldschmidt wrote: > > On Tue, Nov 27, 2018 at 4:15 AM Chris Packham wrote: > > > > On Mon, Nov 26, 2018 at 9:15 PM Simon Goldschmidt > > wrote: > > > > > > On Mon, Nov 26, 2018 at 9:00 AM Chris Packham > > > wrote: > > > > > > > > No mainline board enables CONFIG_MCAST_TFTP and there have been > > > > compilation issues with the code for some time. Additionally, it has a > > > > potential buffer underrun issue (reported as a side note in > > > > CVE-2018-18439). > > > > > > > > Remove the multicast TFTP code but keep the driver API for the future > > > > addition of IPv6. > > > > > > Thanks for taking this. > > > I expect that there will be merge conflicts between this patch any my > > > patch fixing CVE-2018-18439. > > > > > > Joe, how should we proceed? I can rebase my series on top of this if you > > > want. > > > > I actually thought your latest series [1] won't conflict because you > > dropped your version of this. I think your changes should take > > precedence as it is fixing a real issue as opposed to my removal of > > dead code. If anything I should rebase on top of your series. > > Yes I dropped the code you remove here, but still your patch does not > apply for me. I guess this is because our changes are around the same > lines. So one of us needs to rebase after applying the other. > > And since my patch fixes the buffer underrun issue for MCAST_TFTP, > too, you're right that it should probably be pushed first. It was fairly trivial to resolve the conflict, so taking as is. Acked-by: Joe Hershberger Thanks, -Joe > Thanks, > Simon > > > > > [1] - http://patchwork.ozlabs.org/patch/1002685/ > ___ > 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 1/2] net: move ether_crc to tsec driver
On Tue, Nov 27, 2018 at 12:10 AM Simon Goldschmidt
wrote:
>
> On Tue, Nov 27, 2018 at 4:19 AM Chris Packham wrote:
> >
> > On Mon, Nov 26, 2018 at 9:12 PM Simon Goldschmidt
> > wrote:
> > >
> > > On Mon, Nov 26, 2018 at 9:00 AM Chris Packham
> > > wrote:
> > > >
> > > > ether_crc was added to the core net code in commit 53a5c424bf86
> > > > ("multicast tftp: RFC2090") so that other drivers could use it. However
> > > > the only current user of it is tsec.c so move it there.
> > > >
> > > > Signed-off-by: Chris Packham
> > > > ---
> > > >
> > > > drivers/net/tsec.c | 25 +
> > > > include/net.h | 1 -
> > > > net/eth_legacy.c | 24
> > > > 3 files changed, 25 insertions(+), 25 deletions(-)
> > > >
> > > > diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
> > > > index 03a46da2f8a1..9a4fab85e928 100644
> > > > --- a/drivers/net/tsec.c
> > > > +++ b/drivers/net/tsec.c
> > > > @@ -80,6 +80,31 @@ static void tsec_configure_serdes(struct
> > > > tsec_private *priv)
> > > >
> > > > #ifdef CONFIG_MCAST_TFTP
> > > >
> > > > +/* the 'way' for ethernet-CRC-32. Spliced in from Linux lib/crc32.c
> > > > + * and this is the ethernet-crc method needed for TSEC -- and perhaps
> > > > + * some other adapter -- hash tables
> > > > + */
> > > > +#define CRCPOLY_LE 0xedb88320
> > > > +static u32 ether_crc(size_t len, unsigned char const *p)
> > >
> > > I haven't checked, but can't we use lib/crc32.c for this? The
> > > polynomial is the same...
> > >
> >
> > Yes more than likely. I erred on the side of not changing more than
> > absolutely necessary. However given the fact that this code isn't
> > currently run on any platform maybe that's too cautious.
>
> A quick test shows me that a call to 'ether_crc(len, data)' can be
> replaced by 'bitrev32(crc32_no_comp(~0, data, len))'.
> Of course the code size increases as those files have tables (crc
> table: 1K, bitrev table: 256 bytes).
Not sure if tsec devices are ever super memory constrained, but I
could go either way.
Acked-by: Joe Hershberger
But if someone wants to test it on tsec boards and send a
consolidation script. I'm good with that too.
Thanks,
-Joe
> Simon
>
> >
> > > > +{
> > > > + int i;
> > > > + u32 crc;
> > > > +
> > > > + crc = ~0;
> > > > + while (len--) {
> > > > + crc ^= *p++;
> > > > + for (i = 0; i < 8; i++)
> > > > + crc = (crc >> 1) ^ ((crc & 1) ? CRCPOLY_LE : 0);
> > > > + }
> > > > + /* an reverse the bits, cuz of way they arrive -- last-first */
> > > > + crc = (crc >> 16) | (crc << 16);
> > > > + crc = (crc >> 8 & 0x00ff00ff) | (crc << 8 & 0xff00ff00);
> > > > + crc = (crc >> 4 & 0x0f0f0f0f) | (crc << 4 & 0xf0f0f0f0);
> > > > + crc = (crc >> 2 & 0x) | (crc << 2 & 0x);
> > > > + crc = (crc >> 1 & 0x) | (crc << 1 & 0x);
> > >
> > > Does lib/bitrev.c do this job?
> > >
> > > Regards,
> > > Simon
> > >
> > > > + return crc;
> > > > +}
> > > > +
> > > > /* CREDITS: linux gianfar driver, slightly adjusted... thanx. */
> > > >
> > > > /* Set the appropriate hash bit for the given addr */
> > > > diff --git a/include/net.h b/include/net.h
> > > > index 51c099dae2e5..359bfb5ef69f 100644
> > > > --- a/include/net.h
> > > > +++ b/include/net.h
> > > > @@ -289,7 +289,6 @@ const char *eth_get_name(void); /* get
> > > > name of current device */
> > > >
> > > > #ifdef CONFIG_MCAST_TFTP
> > > > int eth_mcast_join(struct in_addr mcast_addr, int join);
> > > > -u32 ether_crc(size_t len, unsigned char const *p);
> > > > #endif
> > > >
> > > >
> > > > diff --git a/net/eth_legacy.c b/net/eth_legacy.c
> > > > index 2a9caa3509b0..d2e16b8fa3da 100644
> > > > --- a/net/eth_legacy.c
> &g
Re: [U-Boot] [PATCH v2] Aquantia: Print information about system interface and firmware version
On Tue, Jan 22, 2019 at 5:14 PM Joe Hershberger
wrote:
>
> On Tue, Nov 6, 2018 at 6:17 AM Valentin-catalin Neacsu
> wrote:
> >
> > Print information about Aquantia firmware loaded on the phy.
> >
> > Signed-off-by: Valentin Catalin Neacsu
> > ---
> > V2:
> > - Fix typo in title. (Clement Peron)
> >
> > drivers/net/phy/aquantia.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
> > index 553069f3dc..2609664c69 100644
> > --- a/drivers/net/phy/aquantia.c
> > +++ b/drivers/net/phy/aquantia.c
> > @@ -22,6 +22,11 @@
> >
> > #define AQUANTIA_SYSTEM_INTERFACE_SR 0xe812
> > #define AQUANTIA_VENDOR_PROVISIONING_REG 0xC441
> > +#define AQUANTIA_FIRMWARE_ID0x20
> > +#define AQUANTIA_RESERVED_STATUS0xc885
> > +#define AQUANTIA_FIRMWARE_MAJOR_MASK0xff00
> > +#define AQUANTIA_FIRMWARE_MINOR_MASK0xff
> > +#define AQUANTIA_FIRMWARE_BUILD_MASK0xf0
> >
> > #define AQUANTIA_USX_AUTONEG_CONTROL_ENA 0x0008
> > #define AQUANTIA_SI_IN_USE_MASK 0x0078
> > @@ -30,6 +35,7 @@
> > int aquantia_config(struct phy_device *phydev)
> > {
> > u32 val = phy_read(phydev, MDIO_MMD_PMAPMD, MII_BMCR);
> > + u32 reg_val1 = 0;
> >
> > if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
> > /* 1000BASE-T mode */
> > @@ -56,6 +62,11 @@ int aquantia_config(struct phy_device *phydev)
> > phy_write(phydev, MDIO_MMD_PHYXS,
> > AQUANTIA_VENDOR_PROVISIONING_REG,
> > AQUANTIA_USX_AUTONEG_CONTROL_ENA);
>
> Is this still needed? This hunk doesn't apply any more.
I fixed up the conflict and will take it as is.
> Thanks,
> -Joe
>
> > + printf("%s: system interface USXGMII\n",
> > + phydev->dev->name);
> > + } else {
> > + printf("%s: system interface XFI\n",
> > + phydev->dev->name);
> > }
> >
> > } else if (phydev->interface == PHY_INTERFACE_MODE_SGMII_2500) {
> > @@ -73,6 +84,16 @@ int aquantia_config(struct phy_device *phydev)
> > val = (val & ~AQUNTIA_SPEED_MSB_MASK) |
> > AQUNTIA_SPEED_LSB_MASK;
> > phy_write(phydev, MDIO_MMD_PMAPMD, MII_BMCR, val);
> > }
> > +
> > + val = phy_read(phydev, MDIO_MMD_VEND1, AQUANTIA_RESERVED_STATUS);
> > + reg_val1 = phy_read(phydev, MDIO_MMD_VEND1, AQUANTIA_FIRMWARE_ID);
> > +
> > + printf("%s: %s Firmware Version %x.%x.%x\n", phydev->dev->name,
> > + phydev->drv->name,
> > + (reg_val1 & AQUANTIA_FIRMWARE_MAJOR_MASK) >> 8,
> > + reg_val1 & AQUANTIA_FIRMWARE_MINOR_MASK,
> > + (val & AQUANTIA_FIRMWARE_BUILD_MASK) >> 4);
> > +
> > return 0;
> > }
> >
> > --
> > 2.17.1
> >
> > ___
> > 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 v2] Aquantia: Print information about system interface and firmware version
On Tue, Nov 6, 2018 at 6:17 AM Valentin-catalin Neacsu
wrote:
>
> Print information about Aquantia firmware loaded on the phy.
>
> Signed-off-by: Valentin Catalin Neacsu
> ---
> V2:
> - Fix typo in title. (Clement Peron)
>
> drivers/net/phy/aquantia.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia.c
> index 553069f3dc..2609664c69 100644
> --- a/drivers/net/phy/aquantia.c
> +++ b/drivers/net/phy/aquantia.c
> @@ -22,6 +22,11 @@
>
> #define AQUANTIA_SYSTEM_INTERFACE_SR 0xe812
> #define AQUANTIA_VENDOR_PROVISIONING_REG 0xC441
> +#define AQUANTIA_FIRMWARE_ID0x20
> +#define AQUANTIA_RESERVED_STATUS0xc885
> +#define AQUANTIA_FIRMWARE_MAJOR_MASK0xff00
> +#define AQUANTIA_FIRMWARE_MINOR_MASK0xff
> +#define AQUANTIA_FIRMWARE_BUILD_MASK0xf0
>
> #define AQUANTIA_USX_AUTONEG_CONTROL_ENA 0x0008
> #define AQUANTIA_SI_IN_USE_MASK 0x0078
> @@ -30,6 +35,7 @@
> int aquantia_config(struct phy_device *phydev)
> {
> u32 val = phy_read(phydev, MDIO_MMD_PMAPMD, MII_BMCR);
> + u32 reg_val1 = 0;
>
> if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
> /* 1000BASE-T mode */
> @@ -56,6 +62,11 @@ int aquantia_config(struct phy_device *phydev)
> phy_write(phydev, MDIO_MMD_PHYXS,
> AQUANTIA_VENDOR_PROVISIONING_REG,
> AQUANTIA_USX_AUTONEG_CONTROL_ENA);
Is this still needed? This hunk doesn't apply any more.
Thanks,
-Joe
> + printf("%s: system interface USXGMII\n",
> + phydev->dev->name);
> + } else {
> + printf("%s: system interface XFI\n",
> + phydev->dev->name);
> }
>
> } else if (phydev->interface == PHY_INTERFACE_MODE_SGMII_2500) {
> @@ -73,6 +84,16 @@ int aquantia_config(struct phy_device *phydev)
> val = (val & ~AQUNTIA_SPEED_MSB_MASK) |
> AQUNTIA_SPEED_LSB_MASK;
> phy_write(phydev, MDIO_MMD_PMAPMD, MII_BMCR, val);
> }
> +
> + val = phy_read(phydev, MDIO_MMD_VEND1, AQUANTIA_RESERVED_STATUS);
> + reg_val1 = phy_read(phydev, MDIO_MMD_VEND1, AQUANTIA_FIRMWARE_ID);
> +
> + printf("%s: %s Firmware Version %x.%x.%x\n", phydev->dev->name,
> + phydev->drv->name,
> + (reg_val1 & AQUANTIA_FIRMWARE_MAJOR_MASK) >> 8,
> + reg_val1 & AQUANTIA_FIRMWARE_MINOR_MASK,
> + (val & AQUANTIA_FIRMWARE_BUILD_MASK) >> 4);
> +
> return 0;
> }
>
> --
> 2.17.1
>
> ___
> 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 u-boot 1/2] net: phy: Add support for accessing MMD PHY registers
On Wed, Jan 16, 2019 at 12:06 PM Carlo Caione wrote: > > Two new helper functions (phy_read_mmd() and phy_write_mmd()) are added > to allow access to the MMD PHY registers. > > The MMD PHY registers can be accessed by two means: > > 1. Using two new MMD access function hooks in the PHY driver. These > functions can be implemented when the PHY driver does not support the > standard IEEE Compatible clause 45 access mechanism described in clause > 22 or if the PHY uses its own non-standard access mechanism. > > 2. The standard clause 45 access extensions to the MMD registers through > the indirection registers (clause 22) in all the other cases. > > Signed-off-by: Carlo Caione This seems like a duplicate of https://patchwork.ozlabs.org/patch/1015782/ The command patch should probably be adapted to use that. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot] net: phy: realtek: Add functions to read PHY's extended registers
On Wed, Jan 16, 2019 at 8:07 AM Carlo Caione wrote: > > According to the datasheet to access the extended registers we have to: > > 1. Write Register 31 Data = 0x0XYZ (Page 0xXYZ) > 2. Read/Write the target Register Data > 3. Write Register 31 Data = 0x or 0xa42 (switch back to IEEE >Standard Registers) > > Hook the missing functions so that we can use the `mdio rx/wx` command to > easily access the extended registers. > > Signed-off-by: Carlo Caione 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: phy: at803x: Address packet drops at low traffic rate due to SmartEEE feature
On Tue, Dec 18, 2018 at 7:22 PM Vladimir Oltean wrote: > > * According to the AR8031 and AR8035 datasheets, smartEEE mode > (active by default) makes the PHY enter sleep after a configurable > idle time. It does this autonomously, without LPI (Low Power Idle) > signals coming from MAC. AR8021 does not appear to support this. > * This patch allows disabling the SmartEEE feature of above PHYs. > * Tested with ping (default of 1 second interval) over back-to-back > RGMII between 2 boards having AR8035 at both ends: > - Without SmartEEE: > 225 packets transmitted, 145 received, 35% packet loss, time 229334ms > - With SmartEEE: > 144 packets transmitted, 144 received, 0% packet loss, time 146378ms > > Signed-off-by: Vladimir Oltean 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: phy: promote phy_{read, write}_mmd_indirect from ti.c to generic code
On Tue, Dec 18, 2018 at 7:22 PM Vladimir Oltean wrote: > > * These are convenience functions for accessing PHY MMD registers > through clause 22 (indirectly through registers 0xD and 0xE), > and are exported in the Linux phylib as well. > > Signed-off-by: Vladimir Oltean 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: mvgbe: fallback phy-mode to GMII
On Tue, Dec 4, 2018 at 12:55 AM Chris Packham wrote: > > Some existing device trees don't specify a phy-mode so fallback to GMII > when a phy-mode is not provided. > > Signed-off-by: Chris Packham 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/1] net: mvneta: Add GPIO configuration support
On Tue, Dec 4, 2018 at 10:39 AM Aditya Prayoga wrote: > > This patch add GPIO configuration support in mvneta driver. > Driver will handle PHY reset. GPIO pins should be set in device tree. > > Ported from mvpp2x > [https://patchwork.ozlabs.org/patch/799654/] > > Initial discussion to port the changes into mvneta > [https://patchwork.ozlabs.org/patch/1005765/] > > Signed-off-by: Aditya Prayoga 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] net: macb: fix mapping of registers
On Thu, Dec 27, 2018 at 11:59 AM Ramon Fried wrote:
>
> Some architectures (MIPS) needs mapping to access IOMEM.
> Fix that.
>
> Fixes: f1dcc19b213d ("net: macb: Convert to driver model")
>
> Signed-off-by: Ramon Fried
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: fix KSZ9031 clock skew for values greater 0ps
On Thu, Nov 29, 2018 at 1:05 PM Andreas Pretzsch wrote: > > For KSZ9021, all skew register fields are 4-bit wide. > For KSZ9031, the clock skew register fields are 5-bit wide. > > The common code in ksz90x1_of_config_group calculating the combined > register value checks if the requested value is above the maximum > and uses this maximum if so. The calculation of this maximum uses > the register width, but the check itself does not. It uses a hardcoded > value of 0xf, which is too low in case of the 5-bit clock (0x1f). > This detail was probably lost during driver unification. > > Effect (only for KSZ9031 clock skews): For values greater 900 (== 0ps), > this silently results in 1860 (== +960ps) instead of the requested one. > > Fix the check by using the bit width instead of hardcoded value(s). > > Signed-off-by: Andreas Pretzsch 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: mvpp2: mdio device per port
On Wed, Nov 21, 2018 at 5:09 AM Baruch Siach wrote: > > Current code forces all ports on a given Ethernet device to use the same > mdio device. In practice different ports might be wired to separate mdio > devices. Move the mdio device from the container struct mvpp2 to the per > port struct mvpp2_port. > > Cc: Ken Ma > Cc: Stefan Chulski > Signed-off-by: Baruch Siach 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] AQUANTIA USXGMII autoneg enable
On Tue, Oct 30, 2018 at 5:44 AM Valentin-catalin Neacsu wrote: > > If System interface protocol is USXGMII then enable USXGMII autoneg > Signed-off-by: Valentin Catalin Neacsu 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] Aquantia: Print information about system interface and firmware version
On Tue, Nov 6, 2018 at 6:17 AM Valentin-catalin Neacsu wrote: > > Print information about Aquantia firmware loaded on the phy. > > Signed-off-by: Valentin Catalin Neacsu 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: mvpp2: fix lookup of mdio registers base address
On Wed, Nov 21, 2018 at 5:08 AM Baruch Siach wrote:
>
> Current mdio base lookup code relies on a 'reg' property at the upper CP
> node. There is no 'reg' property there in current DT files of Armada
> CP110. Use ofnode_get_addr() instead since it provides proper DT address
> translation.
>
> Cc: Ken Ma
> Cc: Stefan Chulski
> Signed-off-by: Baruch Siach
> ---
> drivers/net/mvpp2.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
> index 9b3ab25c1954..23c4da8cebbd 100644
> --- a/drivers/net/mvpp2.c
> +++ b/drivers/net/mvpp2.c
> @@ -4705,21 +4705,22 @@ static int phy_info_parse(struct udevice *dev, struct
> mvpp2_port *port)
> {
> int port_node = dev_of_offset(dev);
> const char *phy_mode_str;
> - int phy_node, mdio_off, cp_node;
> + int phy_node;
> u32 id;
> u32 phyaddr = 0;
> int phy_mode = -1;
> - phys_addr_t mdio_addr;
>
> phy_node = fdtdec_lookup_phandle(gd->fdt_blob, port_node, "phy");
>
> if (phy_node > 0) {
> + ofnode phy_ofnode;
> + fdt_addr_t phy_base;
> +
> phyaddr = fdtdec_get_int(gd->fdt_blob, phy_node, "reg", 0);
> if (phyaddr < 0) {
> dev_err(&pdev->dev, "could not find phy address\n");
> return -1;
> }
> - mdio_off = fdt_parent_offset(gd->fdt_blob, phy_node);
>
> /* TODO: This WA for mdio issue. U-boot 2017 don't have
> * mdio driver and on MACHIATOBin board ports from CP1
> @@ -4728,14 +4729,10 @@ static int phy_info_parse(struct udevice *dev, struct
> mvpp2_port *port)
> * base address. WA should be removed after
> * mdio driver implementation.
> */
> - mdio_addr = fdtdec_get_uint(gd->fdt_blob,
> - mdio_off, "reg", 0);
> -
> - cp_node = fdt_parent_offset(gd->fdt_blob, mdio_off);
> - mdio_addr |= fdt_get_base_address((void *)gd->fdt_blob,
> - cp_node);
>
> - port->priv->mdio_base = (void *)mdio_addr;
> + phy_ofnode = ofnode_get_parent(offset_to_ofnode(phy_node));
> + phy_base = ofnode_get_addr(phy_ofnode);
> + port->priv->mdio_base = (void *)phy_base;
>
> if (port->priv->mdio_base < 0) {
> dev_err(&pdev->dev, "could not find mdio base
> address\n");
Apologies for the delay.
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: explicitly assign errno to return code in case of network failure
On Wed, Nov 21, 2018 at 8:57 AM Thomas RIENOESSL wrote: > > When dealing with two ethernet ports and having "netretry" set > to "once", it could occur that the connection (e.g. an ARP > request) failed, hence the status of the netloop was > "NETLOOP_FAIL". Due to the setting of "netretry", the network > logic would then switch to the other network interface, > assigning "ret" with the return value of "net_start_again()". > If this call succeeded we would return 0 (i.e. success) to > the caller when in reality the network action failed. > > Change-Id: I58b935b0f6c7a300d1dd0058803f7d3c9455b0dc > Signed-off-by: Thomas RIENOESSL > --- > net/net.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/net.c b/net/net.c > index 31cf306ae7..568ba74f78 100644 > --- a/net/net.c > +++ b/net/net.c > @@ -657,6 +657,7 @@ restart: > /* Invalidate the last protocol */ > eth_set_last_protocol(BOOTP); > debug_cond(DEBUG_INT_STATE, "--- net_loop Fail!\n"); > + ret = -ENONET; > goto done; > > case NETLOOP_CONTINUE: Apologies for the delay. 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: remove duplicate definition of ETHADDR_WILDCARD
On Tue, Jan 22, 2019 at 1:26 AM Simon Goldschmidt wrote: > > Hi Joe, > > On Tue, Jan 15, 2019 at 10:00 AM Joe Hershberger > wrote: > > > > On Thu, Nov 22, 2018 at 9:58 AM Simon Goldschmidt > > wrote: > > > > > > ETHADDR_WILDCARD is defined as the same value in both env_flags.h > > > and env_callback.h > > > > > > As env_callback.h includes env_flags.h, remove the duplicate definition > > > from env_callback.h > > > > > > Signed-off-by: Simon Goldschmidt > > > > Acked-by: Joe Hershberger > > I don't want to be annoying, but could you tell me when this patch > (and the other > 3 I have pending in patchwork that are assigned to you) will make it > into the main > repository? Or if there's anything preventing that? I sent them mid of > November... Sorry for the delay. I'll be build testing everything this week and if all goes smoothly, I'll send a PR then. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: dm: fec: Fix regulator enable when using DM_REGULATOR
On Tue, Jan 15, 2019 at 11:27 AM Adam Ford wrote:
>
> When DM_REGULATOR is enabled, the driver attempts to call
> regulator_autoset() which expects the regulators to be on at boot
> and/or always on and fails if they are not true.
> For a more generic approach, this patch just calls
> regulator_set_enable() which shouldn't have such restrictions.
>
> Fixes: ad8c43cbcafb ("net: dm: fec: Support the phy-supply
> binding")
>
> Signed-off-by: Adam Ford
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: remove duplicate definition of ETHADDR_WILDCARD
On Thu, Nov 22, 2018 at 9:58 AM Simon Goldschmidt wrote: > > ETHADDR_WILDCARD is defined as the same value in both env_flags.h > and env_callback.h > > As env_callback.h includes env_flags.h, remove the duplicate definition > from env_callback.h > > Signed-off-by: Simon Goldschmidt 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: fix env flags for eth10addr and above
On Thu, Nov 22, 2018 at 10:06 AM Simon Goldschmidt wrote: > > With CONFIG_REGEX enabled, ETHADDR_WILDCARD is set up for up to 10 > interfaces (0..9) as the number can only have one digit. > > On boards with more than 10 interfaces, this leads to the protection > and format checks being absent for eth10addr and above. > > Fix this by changing ETHADDR_WILDCARD from "\\d?" to "\\d*" to allow > more than one digit. > > Signed-off-by: Simon Goldschmidt 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: fix env flags for eth10addr and above
Hi Simon,
On Mon, Jan 14, 2019 at 10:29 AM Tom Rini wrote:
>
> On Mon, Jan 14, 2019 at 04:42:10PM +0100, Simon Goldschmidt wrote:
> > Am 14.12.2018 um 14:28 schrieb Tom Rini:
> > >On Fri, Dec 14, 2018 at 09:56:19AM +0100, Simon Goldschmidt wrote:
> > >
> > >>+Tom
> > >>
> > >>On Sun, Dec 9, 2018 at 9:51 PM Simon Goldschmidt
> > >> wrote:
> > >>>
> > >>>Am 22.11.2018 um 17:06 schrieb Simon Goldschmidt:
> > With CONFIG_REGEX enabled, ETHADDR_WILDCARD is set up for up to 10
> > interfaces (0..9) as the number can only have one digit.
> >
> > On boards with more than 10 interfaces, this leads to the protection
> > and format checks being absent for eth10addr and above.
> >
> > Fix this by changing ETHADDR_WILDCARD from "\\d?" to "\\d*" to allow
> > more than one digit.
> >
> > Signed-off-by: Simon Goldschmidt
> > ---
> >
> > include/env_flags.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/env_flags.h b/include/env_flags.h
> > index cc2c34f939..23744e395c 100644
> > --- a/include/env_flags.h
> > +++ b/include/env_flags.h
> > @@ -38,7 +38,7 @@ enum env_flags_varaccess {
> >
> > #ifdef CONFIG_CMD_NET
> > #ifdef CONFIG_REGEX
> > -#define ETHADDR_WILDCARD "\\d?"
> > +#define ETHADDR_WILDCARD "\\d*"
> > #else
> > #define ETHADDR_WILDCARD
> > #endif
> >
> > >>>
> > >>>Ping?
> > >>
> > >>I haven't gotten an answer to this for nearly one month. It's a small
> > >>change, can this go in for v2019.01 please?
> > >
> > >I'd filed this off to Joe to grab since it is indeed small and a
> > >clean-up.
Apologies for the dead air... I was out for about a month and then the
holidays hit. I've been trying to catch up on things that languished
in that time and missed this one.
-Joe
> >
> > Will you be taking this after the release or is there anything missing? It's
> > assigned to you in patchwork but I didn't get any real reply...
>
> Yes, I'll be picking it up then, thanks for your patience.
>
> --
> Tom
> ___
> 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 v2 5/7] net: Fix error handling in sb_eth_raw_ofdata_to_platdata()
On Mon, Jan 7, 2019 at 5:47 PM Simon Glass wrote: > > At present this stores the error number in an unsigned int so an error is > never detected. Use the existing signed variable instead. > > Signed-off-by: Simon Glass Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v9 09/10] tftp: prevent overwriting reserved memory
On Wed, Dec 19, 2018 at 1:04 PM Simon Goldschmidt
wrote:
>
> This fixes CVE-2018-18439 ("insufficient boundary checks in network
> image boot") by using lmb to check for a valid range to store
> received blocks.
>
> Signed-off-by: Simon Goldschmidt
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: Add clause 45 identifier to phy_device
On Fri, Nov 16, 2018 at 12:26 AM Pankaj Bansal wrote: > > The phy devices can be accessed via clause 22 or via clause 45. > This information can be deduced when we read phy id. if the phy id > is read without giving any MDIO Manageable Device Address (MMD), then > it conforms to clause 22. otherwise it conforms to clause 45. > > Signed-off-by: Pankaj Bansal Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot 0/2] net: designware: add meson meson compatibles
On Fri, Nov 9, 2018 at 8:21 AM Neil Armstrong wrote: > > Add the compatible strings in the Synopsys DWMAC driver for : > - The Amlogic GXBB (and other GX) SoC > - The Amlogic AXG (and other GX) SoC > > Neil Armstrong (2): > net: designware: add meson meson gxbb comptatible > net: designware: add meson meson axg compatible Hi Neil, Trying to catch up on patches - I don't see this series in patchwork - should it be? Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: designware: clear padding bytes
On Sat, Nov 17, 2018 at 3:26 AM Simon Goldschmidt wrote: > > Short frames are padded to the minimum allowed size of 60 bytes. > However, the designware driver sends old data in these padding bytes. > It is common practice to zero out these padding bytes ro prevent > leaking memory contents to other hosts. > > Fix the padding code to zero out the padded bytes at the end. > > Tested on socfpga gen5. > > Signed-off-by: Simon Goldschmidt 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 7/8] net: remove CONFIG_MCAST_TFTP
Hi Simon,
Thanks for tackling this.
On Sat, Nov 17, 2018 at 6:31 AM Simon Goldschmidt
wrote:
>
> This option seems unused as no mainline board enables it and it does
> not compile since some years.
>
> Additionally, it has a potential buffer underrun issue (reported as
> a side node in CVE-2018-18439).
>
> Instead of trying to fix a thing noone seems to use, let's rather
> drop dead code.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> Changes in v2:
> - this patch is new in v2
>
> README | 9 --
> drivers/net/rtl8139.c| 9 --
> drivers/net/tsec.c | 52
> drivers/usb/gadget/ether.c | 3 -
> include/net.h| 17 ---
> net/eth-uclass.c | 4 -
> net/eth_legacy.c | 46
> net/net.c| 9 +-
> net/tftp.c | 223 +--
I think the TFTP stuff can be removed, but multicast in general
probably not, since I believe IPv6 support requires it. I guess we
could put it back at that time, but I'm a bit concerned that we will
diverge and make that work harder. Maybe it's feasible to simply stop
guarding multicast support in the core and drivers with the TFTP
config and enable it at all times. The code size on that side is
minimal.
Thanks,
-Joe
> scripts/config_whitelist.txt | 1 -
> 10 files changed, 2 insertions(+), 371 deletions(-)
>
> diff --git a/README b/README
> index a46c7c63a4..97a3e9a84b 100644
> --- a/README
> +++ b/README
> @@ -1429,15 +1429,6 @@ The following options need to be configured:
> forwarded through a router.
> (Environment variable "netmask")
>
> -- Multicast TFTP Mode:
> - CONFIG_MCAST_TFTP
> -
> - Defines whether you want to support multicast TFTP as per
> - rfc-2090; for example to work with atftp. Lets lots of
> targets
> - tftp down the same boot image concurrently. Note: the
> Ethernet
> - driver in use must provide a function: mcast() to join/leave a
> - multicast group.
> -
> - BOOTP Recovery Mode:
> CONFIG_BOOTP_RANDOM_DELAY
>
> diff --git a/drivers/net/rtl8139.c b/drivers/net/rtl8139.c
> index 590f8ce154..79acd64bc0 100644
> --- a/drivers/net/rtl8139.c
> +++ b/drivers/net/rtl8139.c
> @@ -183,12 +183,6 @@ static void rtl_reset(struct eth_device *dev);
> static int rtl_transmit(struct eth_device *dev, void *packet, int length);
> static int rtl_poll(struct eth_device *dev);
> static void rtl_disable(struct eth_device *dev);
> -#ifdef CONFIG_MCAST_TFTP/* This driver already accepts all b/mcast */
> -static int rtl_bcast_addr(struct eth_device *dev, const u8 *bcast_mac, u8
> set)
> -{
> - return (0);
> -}
> -#endif
>
> static struct pci_device_id supported[] = {
> {PCI_VENDOR_ID_REALTEK, PCI_DEVICE_ID_REALTEK_8139},
> @@ -229,9 +223,6 @@ int rtl8139_initialize(bd_t *bis)
> dev->halt = rtl_disable;
> dev->send = rtl_transmit;
> dev->recv = rtl_poll;
> -#ifdef CONFIG_MCAST_TFTP
> - dev->mcast = rtl_bcast_addr;
> -#endif
>
> eth_register (dev);
>
> diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
> index 03a46da2f8..614097c6ce 100644
> --- a/drivers/net/tsec.c
> +++ b/drivers/net/tsec.c
> @@ -78,52 +78,6 @@ static void tsec_configure_serdes(struct tsec_private
> *priv)
> 0, TBI_CR, CONFIG_TSEC_TBICR_SETTINGS);
> }
>
> -#ifdef CONFIG_MCAST_TFTP
> -
> -/* CREDITS: linux gianfar driver, slightly adjusted... thanx. */
> -
> -/* Set the appropriate hash bit for the given addr */
> -
> -/*
> - * The algorithm works like so:
> - * 1) Take the Destination Address (ie the multicast address), and
> - * do a CRC on it (little endian), and reverse the bits of the
> - * result.
> - * 2) Use the 8 most significant bits as a hash into a 256-entry
> - * table. The table is controlled through 8 32-bit registers:
> - * gaddr0-7. gaddr0's MSB is entry 0, and gaddr7's LSB is entry
> - * 255. This means that the 3 most significant bits in the
> - * hash index which gaddr register to use, and the 5 other bits
> - * indicate which bit (assuming an IBM numbering scheme, which
> - * for PowerPC (tm) is usually the case) in the register holds
> - * the entry.
> - */
> -#ifndef CONFIG_DM_ETH
> -static int tsec_mcast_addr(struct eth_device *dev, const u8 *mcast_mac, u8
> set)
> -#else
> -static int tsec_mcast_addr(struct udevice *dev, const u8 *mcast_mac, int set)
> -#endif
> -{
> - struct tsec_private *priv = (struct tsec_private *)dev->priv;
> - struct tsec __iomem *regs = priv->regs;
> - u32 result, value;
> - u8 whichbit, whichreg;
> -
> - result = ether_crc(MAC_ADDR_LEN, mcast_mac);
> - whichbit = (result >> 24) & 0x1f; /* the 5 LSB = which bit to set */
> - whichreg = result >> 29; /* the 3 MSB = which reg to set it in */
> -
>
Re: [U-Boot] [PATCH 1/2] net: designware: fix tx packet length
On Sat, Nov 17, 2018 at 3:25 AM Simon Goldschmidt wrote: > > The designware driver has a bug in setting the tx length into the dma > descriptor: it always or's the length into the descriptor without > zeroing out the length mask before. > > This results in occasional packets being transmitted with a length > greater than they should be (trailer). Due to the nature of Ethernet > allowing such a trailer, most packets seem to be parsed fine by remote > hosts, which is probably why this hasn't been noticed. > > Fix this by correctly clearing the size mask before setting the new > length. > > Tested on socfpga gen5. > > Signed-off-by: Simon Goldschmidt Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities
Hi Simon,
On Wed, Nov 14, 2018 at 1:07 PM Simon Goldschmidt
wrote:
>
> On 14.11.2018 16:51, Simon Goldschmidt wrote:
> > On 14.11.2018 16:35, Daniele Bianco wrote:
> >> On Wed, Nov 14, 2018 at 04:26:17PM +0100, Andrea Barisani wrote:
> >>> On Wed, Nov 14, 2018 at 04:13:00PM +0100, Simon Goldschmidt wrote:
> On 14.11.2018 15:45, Andrea Barisani wrote:
> > On Wed, Nov 14, 2018 at 01:03:12PM +0100, Simon Goldschmidt wrote:
> >> On 14.11.2018 12:52, Andrea Barisani wrote:
> >>> On Tue, Nov 13, 2018 at 09:57:23PM +0100, Simon Goldschmidt wrote:
> On 06.11.2018 15:51, Andrea Barisani wrote:
> > [..]
> > The issue can be exploited by several means:
> >
> >- An excessively large crafted boot image file is parsed by
> > the
> > `tftp_handler` function which lacks any size checks,
> > allowing the memory
> > overwrite.
> >
> >- A malicious server can manipulate TFTP packet sequence
> > numbers to store
> > downloaded file chunks at arbitrary memory locations,
> > given that the
> > sequence number is directly used by the `tftp_handler`
> > function to calculate
> > the destination address for downloaded file chunks.
> >
> > Additionally the `store_block` function, used to store
> > downloaded file
> > chunks in memory, when invoked by `tftp_handler` with a
> > `tftp_cur_block`
> > value of 0, triggers an unchecked integer underflow.
> >
> > This allows to potentially erase memory located before the
> > `loadAddr` when
> > a packet is sent with a null, following at least one valid
> > packet.
> Do you happen to have more details on this suggested integer
> underflow? I
> have tried to reproduce it, but I failed to get a memory write
> address
> before 'load_addr'. This is because the 'store_block' function does
> not
> directly use the underflowed integer as a block counter, but adds
> 'tcp_block_wrap_offset' to this offset.
>
> To me it seems like alternating between '0' and 'not 0' for the block
> counter could increase memory overwrites, but I fail to see how you
> can use
> this to store chunks at arbitrary memory locations. All you can do is
> subtract one block size from 'tftp_block_wrap_offset'...
>
> Simon
>
> >>> Hello Simon,
> >>>
> >>> the integer underflow can happen if a malicious TFTP server, able to
> >>> control
> >>> the TFTP packets sequence number, sends a crafted packet with
> >>> sequence number
> >>> set to 0 during a flow.
> >>>
> >>> This happens because, within the store_block() function, the 'block'
> >>> argument
> >>> is declared as 'int' and when it is invoked inside tftp_handler()
> >>> (case
> >>> TFTP_DATA) this value is passed by doing 'tftp_cur_block - 1' (where
> >>> tftp_cur_block is the sequence number extracted from the tftp packet
> >>> without
> >>> any previous check):
> >>>
> >>> static inline void store_block(int block, uchar *src, unsigned len)
> >>>^ can have negative values
> >>> (e.g. -1)
> >>> {
> >>> ulong offset = block * tftp_block_size +
> >>> tftp_block_wrap_offset;
> >>> ^
> >>> here if block is -1 the result stored onto offset would
> >>> be a very
> >>> large unsigned number, due to type conversions
> >> And this is exatclty my point. This might be bad coding style, but for
> >> me it
> >> works: 'block' is an 'int' and is '-1', so 'block * tftp_block_size' is
> >> '-512'. Now from the code flow in tftp_handler(), it's clear that if
> >> we come
> >> here with tftp_cur_block == 0 (so 'block' is -1),
> >> 'tftp_block_wrap_offset'
> >> is not 0 but some positive value 'x * tftp_block_size' (see function
> >> 'update_block_number').
> >>
> >> So the resulting 'offset' is '-512 + (x * 512)' where 'x > 0'. I still
> >> fail
> >> to see how this can be a very large positive number resulting in an
> >> effective negative offset or arbitrary write.
> >>
> > I understand your point, however what does happen when we enter the
> > 'case
> > TFTP_DATA' and we are in the first block received, so we trigger
> > new_transfer() that sets the tftp_block_wrap_offset to 0 *and*
> > tftp_mcast_active is set?
> >
> > I don't see any protection for this case for the underflow, am I wrong?
> >
> > static void new_transfer(void)
> > {
> >tftp_prev_block
Re: [U-Boot] Pull request: u-boot-net.git master
On Mon, Nov 5, 2018 at 10:06 PM Tom Rini wrote: > > On Mon, Nov 05, 2018 at 11:51:41AM -0600, Joe Hershberger wrote: > > > Hi Tom, > > > > Built successfully on Travis: > > https://travis-ci.org/jhershbe/u-boot/builds/450020193 > > > > The following changes since commit 5ef76e59c12c79d106ebda70b710468aa6bd8b75: > > > > Merge branch 'master' of git://git.denx.de/u-boot-sh (2018-11-04 08:12:21 > > -0500) > > > > are available in the git repository at: > > > > > > git://git.denx.de/u-boot-net.git master > > > > for you to fetch changes up to 79d8127168e211f4745bd2183a3338c6c4e2d003: > > > > driver: net: ti: keystone_net: switch to use common mdio lib (2018-11-05 > > 10:42:01 -0600) > > > > Given that the release is one week away, rather than sit on this for > now, applied to u-boot/next, thanks! Works for me. Thanks, -Joe > -- > Tom > ___ > 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] aspeed: ast2500: fix missing break in D2PLL clock enablement
Hi Cédric, https://patchwork.ozlabs.org/patch/990058/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: ftgmac100: convert to driver model
Hi Cédric, https://patchwork.ozlabs.org/patch/990052/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] aspeed: ast2500: fix D2-PLL clock setting in RGMII mode
Hi Cédric, https://patchwork.ozlabs.org/patch/990063/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] driver: net: ti: introduce common mdio support library
Hi Grygorii, https://patchwork.ozlabs.org/patch/991704/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: ftgmac100: add MDIO bus and phylib support
Hi Cédric, https://patchwork.ozlabs.org/patch/990056/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: ftgmac100: use the aligned() macro
Hi Cédric, https://patchwork.ozlabs.org/patch/990051/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: ftgmac100: Add support for the Aspeed SoC
Hi Cédric, https://patchwork.ozlabs.org/patch/990055/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] aspeed: Update ast2500 SoC DTS file to Linux v4.17-rc6 level
Hi Cédric, https://patchwork.ozlabs.org/patch/990060/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: ftgmac100: use the BIT() macro
Hi Cédric, https://patchwork.ozlabs.org/patch/990050/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: ftgmac100: convert the RX/TX descriptor arrays
Hi Cédric, https://patchwork.ozlabs.org/patch/990053/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] driver: net: ti: keystone_net: switch to use common mdio lib
Hi Grygorii, https://patchwork.ozlabs.org/patch/991709/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] driver: net: ti: cpsw: switch to use common mdio lib
Hi Grygorii, https://patchwork.ozlabs.org/patch/991708/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: ftgmac100: handle timeouts when transmitting
Hi Cédric, https://patchwork.ozlabs.org/patch/990061/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] aspeed: Activate ethernet devices on the ast2500 Eval Board
Hi Cédric, https://patchwork.ozlabs.org/patch/990062/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: ftgmac100: add clock support
Hi Cédric, https://patchwork.ozlabs.org/patch/990059/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] driver: net: consolidate ti's code in separate folder
Hi Grygorii, https://patchwork.ozlabs.org/patch/991712/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] configs: net: convert DRIVER_TI_KEYSTONE_NET kconfig
Hi Grygorii, https://patchwork.ozlabs.org/patch/991713/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] driver: net: ti: cpsw: update to use SPDX identifier
Hi Grygorii, https://patchwork.ozlabs.org/patch/991710/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: ftgmac100: use setbits_le32() in the reset method
Hi Cédric, https://patchwork.ozlabs.org/patch/990057/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] drivers: net: keystone_net: drop non dm code
Hi Grygorii, https://patchwork.ozlabs.org/patch/991707/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: mscc: add support for VSC8574 PHY
Hi Quentin, https://patchwork.ozlabs.org/patch/991334/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
