[U-Boot] Switch MVPP2 to use new MVMDIO - how do I move this along?
Hi My submission below went through several iterations, the last of which was requests to squash some commits. I *think* I performed all the requested modifications several months ago. I am new with this email-based patch system so not sure if I'm missing a step in the submission/review process and wondering how to move this along. Please advise https://patchwork.ozlabs.org/project/uboot/list/?series=125471 [apologies if dup] Thanks --Nevo ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] net: mvpp2: Replace SMI implementation with marvell MDIO API
On Wed, Aug 14, 2019 at 11:39 AM Joe Hershberger wrote: > > On Fri, Aug 2, 2019 at 12:54 PM wrote: > > > > From: Ken Ma > > > > - > > -static int mvpp2_recv(struct udevice *dev, int flags, uchar **packetp) > > +int mvpp2_recv(struct udevice *dev, int flags, uchar **packetp) > > Why does this need to be visible outside of this translation unit? Hi Joe Yes you are right, it should remain static. This was in the downstream commit from Ken I pulled in - I reversed that and made it static again in my later commit in same patchset https://patchwork.ozlabs.org/patch/1142905/ let me know if it is preferred to rewrite this commit (I just don't know what the right way when submitting changes by others where the others' org instructed them to abandoned them) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] net: mvpp2: allow MDIO registration for fixed links
Thanks Simon
you are correct I should have not selected this commit from the
downstream mvl repo as
this feature of phy_connect is now in upstream (the downstream repo is
2018.12 based)
I will remove and resubmit the set
On Fri, Aug 2, 2019 at 3:01 PM Simon Goldschmidt
wrote:
>
> Am 02.08.2019 um 19:54 schrieb nhed+ub...@starry.com:
> > From: Igal Liberman
> >
> > Currently, there are 2 valid cases for interface, PHY
> > and mdio relation:
> >- If an interface has PHY handler, it'll call
> > mdio_mii_bus_get_from_phy(), which will register
> > MDIO bus.
> >- If we want to use fixed-link for an interface,
> > PHY handle is not defined in the DTS, and no
> > MDIO is registered.
> >
> > There is a third case, for some boards (with switch),
> > the MDIO is used for switch configuration, but the interface
> > itself uses fixed link. This patch allows this option by
> > checking if fixed-link subnode is defined, in this case,
> > MDIO bus is registers, but the PHY address is set to
> > PHY_MAX_ADDR for this interface, so this interface will
> > not try to access the PHY later on.
>
> Instead of ad-hoc coding this, would it work to use "phy_connect()",
> which also checks for fixed-link?
>
> Regards,
> Simon
>
> >
> > In addition, remove unnecessary check after
> > calling fdtdec_get_int().
> >
> > This squahses a subsequent fix by same author
> >
> > Signed-off-by: Igal Liberman
> > Reviewed-by: Kostya Porotchkin
> > Reviewed-by: Stefan Chulski
> > Signed-off-by: Nevo Hed
> > ---
> >
> > drivers/net/mvpp2.c | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/mvpp2.c b/drivers/net/mvpp2.c
> > index 5f908113f2..da550450eb 100644
> > --- a/drivers/net/mvpp2.c
> > +++ b/drivers/net/mvpp2.c
> > @@ -4707,6 +4707,7 @@ static int phy_info_parse(struct udevice *dev, struct
> > mvpp2_port *port)
> > u32 phyaddr = 0;
> > int phy_mode = -1;
> > int ret;
> > + int fixed_link = 0;
> >
> > /* Default mdio_base from the same eth base */
> > if (port->priv->hw_version == MVPP21)
> > @@ -4715,16 +4716,17 @@ static int phy_info_parse(struct udevice *dev,
> > struct mvpp2_port *port)
> > port->mdio_base = port->priv->iface_base + MVPP22_SMI;
> >
> > phy_node = fdtdec_lookup_phandle(gd->fdt_blob, port_node, "phy");
> > + fixed_link = fdt_subnode_offset(gd->fdt_blob, port_node,
> > "fixed-link");
> >
> > 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(>dev, "could not find phy address\n");
> > - return -1;
> > + if (fixed_link != -FDT_ERR_NOTFOUND) {
> > + /* phy_addr is set to invalid value for fixed links */
> > + phyaddr = PHY_MAX_ADDR;
> > + } else {
> > + phyaddr = fdtdec_get_int(gd->fdt_blob, phy_node,
> > + "reg", 0);
> > }
> > +
> > ret = mdio_mii_bus_get_from_phy(phy_node, >bus);
> > if (ret)
> > return ret;
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm: dts: Set custom names for cp110 master/slave MDIO buses
For context from upstream linux, https://github.com/torvalds/linux/commit/f66b2aff46eaf0825dbe1560e28fcb845dd2a215 I was intending to submit the parallel change here once fully tested end-end on our hardware, but if not too late my proposal is to name the above nodes as "cpm-mdio" & "cps-mdio" On Tue, Jul 23, 2019 at 1:03 PM Nevo Hed wrote: > > Sorry for the late input > > The cp110s have an mdio and an xmdio so > Locally I have been naming them cpm-xmdio, cpm-mdio, cps-xmdio, cps-mdio > > I knew the new field is coming but didn't catch that the 'dtsi's patch > > [also apologies if you get this a second time] > > On Mon, Jul 22, 2019 at 8:30 PM Joe Hershberger > wrote: > > > > On Wed, Jul 17, 2019 at 10:12 AM Alex Marginean > > wrote: > > > > > > Implicitly Marvell MDIO driver uses DT node names for devices, but in this > > > case that is not unique. Set MDIO device names for master/slave to > > > cpm/cps. > > > > > > Signed-off-by: Alex Marginean > > > > Acked-by: Joe Hershberger > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm: dts: Set custom names for cp110 master/slave MDIO buses
Sorry for the late input The cp110s have an mdio and an xmdio so Locally I have been naming them cpm-xmdio, cpm-mdio, cps-xmdio, cps-mdio I knew the new field is coming but didn't catch that the 'dtsi's patch [also apologies if you get this a second time] On Mon, Jul 22, 2019 at 8:30 PM Joe Hershberger wrote: > > On Wed, Jul 17, 2019 at 10:12 AM Alex Marginean > wrote: > > > > Implicitly Marvell MDIO driver uses DT node names for devices, but in this > > case that is not unique. Set MDIO device names for master/slave to > > cpm/cps. > > > > Signed-off-by: Alex Marginean > > Acked-by: Joe Hershberger > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm: dts: Set custom names for cp110 master/slave MDIO buses
Sorry for the late input The cp110s have an mdio and an xmdio so Locally I have been naming them cpm-xmdio, cpm-mdio, cps-xmdio, cps-mdio I knew the new field is coming but didn't catch that the 'dtsi's patch On Mon, Jul 22, 2019 at 8:30 PM Joe Hershberger wrote: > > On Wed, Jul 17, 2019 at 10:12 AM Alex Marginean > wrote: > > > > Implicitly Marvell MDIO driver uses DT node names for devices, but in this > > case that is not unique. Set MDIO device names for master/slave to > > cpm/cps. > > > > Signed-off-by: Alex Marginean > > Acked-by: Joe Hershberger > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 1/2 v3] net: introduce MDIO DM class for MDIO devices
Hi Alex In another thread (https://lists.denx.de/pipermail/u-boot/2019-June/371933.html) I asked Ken (before learning of their cut-backs) if I should take a stab at re-integrating his work where Joe also pointed out the impending acceptance of your work. I'm not sure where we left off here in this thread and wondering if you are working on that or not. Ive been staring at this for a bit and ready to take a stab at it if you are not. if easier - i'm `nhed73` on the #u-boot irc channel Thanks ---Nevo On Tue, Jun 11, 2019 at 8:04 AM Alexandru Marginean wrote: > > Hi Ken, > > On 6/11/2019 12:44 PM, Ken Ma wrote: > > Hi Alex > > > > Thanks a lot for your information! > > > > I think our patches have no essential difference. > > The 2 patches have only small implementation difference: > > In my patch, mii bus ops functions(read/write/reset...) need to be > > implemented while in your patch mdio bus functions need to be > > implemented and then mii bus ops functions will call mdio bus ops > > functions. > I had planned to reuse those existed mii ops functions such as > > smc911x_miiphy_read/ smc911x_miiphy_write/ sun8i_mdio_read/ > > sun8i_mdio_write... then it is easy for turning old mdio driver to > > DM. > > > Now I am not working on u-boot, so I am sorry that I will not do the > > pulling work. > > > > Yours, > > Ken > > OK, I think I get what you wanted to do. Either way it's not too > difficult to convert existing MDIOs to DM, but they have to start using > struct udevice. That's similar to what was done on DM_ETH and others. > > The helpers mapping eth/phy/mdio make sense and could be useful, that's > something I'll try to look into. > > Thank you! > Alex > > > > > > -Original Message- > > From: Alex Marginean > > Sent: Tuesday, June 11, 2019 9:18 AM > > To: joe.hershber...@ni.com; Ken Ma > > Cc: u-boot ; Joseph Hershberger > > > > Subject: [EXT] Re: [U-Boot] [PATCH 1/2 v3] net: introduce MDIO DM class for > > MDIO devices > > > > External Email > > > > -- > > +Ken, > > > > Hi Joe, > > > > On 6/10/2019 11:25 PM, Joe Hershberger wrote: > >> On Mon, Jun 3, 2019 at 11:11 AM Alex Marginean > >> wrote: > >>> > >>> Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as > >>> stand-alone devices. Useful in particular for systems that support > >>> DM_ETH and have a stand-alone MDIO hardware block shared by multiple > >>> Ethernet interfaces. > >>> > >>> Signed-off-by: Alex Marginean > >>> --- > >>> > >>> Changes in v2: > >>> - fixed several comments using wrong API names > >>> - dropped dm_ from names of internal functions that don't use > >>> udevice * > >>> - fixed UCLASS driver name > >>> - added missing mdio_unregister in dm_mdio_pre_remove > >>> - added a comment on why spaces in names aren't ok > >>> - added a comment on how static mdio_read/_write/_reset > >>> functions > >>> are used > >>> Changes in v3: > >>> - none > >> > >> > >> Not sure if you already noticed this [1] or not, but there may be > >> something there that you want to incorporate or maybe not. > >> > >> Cheers, > >> -Joe > >> > >> [1] - https://patchwork.ozlabs.org/patch/939726/ > >> > > > > I didn't notice it, thanks for pointing it out! > > Apart from the obvious overlap of adding UCLASS_MDIO and code like > > _post_probe they seem to deal with different needs. > > > > Ken, can you please take a look at the patch I sent? It has a wrapper over > > phy_connect, but provides no helpers on how the caller would get the PHY > > ADDR. Do you want to try pulling the API you add on top of the patch I > > sent, or do you want me to try? It looks like it would work with minimal > > effort. > > > > Thank you! > > Alex > > > > ___ > 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
[U-Boot] Did anything ever happen with mvmdio / marvell xsmi support?
Hi All Last I see is version 4 of a patchset that is almost a year old with some change requests within - [PATCH v4 1/2] dm: mdio: add a uclass for MDIO (https://lists.denx.de/pipermail/u-boot/2018-July/334118.html) - [PATCH v4 2/2] mdio: add marvell MDIO driver (https://lists.denx.de/pipermail/u-boot/2018-July/333750.html) I see no trace of this on u-boot repos (i think I looked at the primary, the `-net`, the `-marvell` and even the `-dm` repos) I do see similar work in Marvell's public github repo (g...@github.com:MarvellEmbeddedProcessors/u-boot-marvell.git) but said repo/branch seems to be significantly outdated relative to u-boot master. - Ken, Is there intention on your side to wrap this up? - If not or if if yes but not in the near future we could give it a go, is there anything that I should be aware of? Thanks --Nevo p.s. new to the mailing list - feel free to hit me over the head or direct me if not following correct protocol. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
