Hi Nevo,
On 6/14/2019 7:55 PM, Nevo Hed wrote:
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.
I am planning to add helpers to MDIO uclass, along the lines Ken sent
initially, on top of the current patch. It looks like the helpers would
fit just fine. I didn't get to do it yet though.
One difference between the two DM MDIO implementations is the way MDIO
ops work, the patch I sent abstracts away the legacy mii_bus from DM
MDIO driver. I would keep that as it, which means a bit more rework on
the marvell driver. I didn't look into this in detail yet.
I think I can send a version of the helpers in [1] in about a week,
maybe more, right now I'm trying to get MDIO MUX DM support out for
review plus some updates for the NXP platform I'm working on. I can
take a stab at porting the marvell driver too, but I can't test it.
If you want to put some time into this right now feel free to do it :)
if easier - i'm `nhed73` on the #u-boot irc channel
Thanks
---Nevo
I can join if you want to discuss details, let me know.
Thanks!
Alex
On Tue, Jun 11, 2019 at 8:04 AM Alexandru Marginean
<alexandru.margin...@nxp.com> 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 <alexm.ossl...@gmail.com>
Sent: Tuesday, June 11, 2019 9:18 AM
To: joe.hershber...@ni.com; Ken Ma <m...@marvell.com>
Cc: u-boot <u-boot@lists.denx.de>; Joseph Hershberger
<joseph.hershber...@ni.com>
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 <alexm.ossl...@gmail.com> 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 <alexm.ossl...@gmail.com>
---
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 mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
