On Mon, Feb 5, 2018 at 1:17 AM, Michal Simek <michal.si...@xilinx.com> wrote: > Hi Joe, > > On 2.2.2018 20:35, Joe Hershberger wrote: >> Hi Michal, >> >> On Thu, Feb 1, 2018 at 6:42 AM, Michal Simek <michal.si...@xilinx.com> wrote: >>> Find out MDIO bus and enable MDIO access to it if this is done via >>> different controller. >>> >>> Signed-off-by: Michal Simek <michal.si...@xilinx.com> >>> --- >>> >>> Hi Joe, >>> >>> this is the code I have hacked a year ago for ZynqMP where we can have >>> configuration that 4 gems are enabled but they share the same MDIO bus >>> which can be assigned to only gem. Normally recommendation is that you >>> should assign it to IP which is required for boot and this is suitable I >>> would say for almost everybody. >>> But for testing purpose it will be good to support sharing mdio bus >>> between others IPs. This hack is "enabling" this for others gem but not >>> across different ethernet drivers. >> >> Seems practical. >> >>> And my question is if there is any solution which can be used now for >>> handling it. Or even this should work even now but we do something >>> wrong. >> >> I would envision some DM way to model the NIC, the MDIO bus, and the >> PHY separately. The big roadblock is that the DTS format is different >> for every NIC. > > Is it really that different? There should be phy handle which is > pointing to actual phy and that should be enough to recognize parents > and IP responsible for MDIO bus.
The point is different drivers express the relationship with varying levels of implication, so there are a number of ways people describe it. >>> I am refreshing this topic based on communication with Tomasz >>> Gorochowik when he wanted to separate mdio part but it is not compatible >>> with solution used in Linux which is pattern we should follow. >> >> We do the same thing on our 7020 products. > > What exactly are you doing on 7020? We are using a single MDIO interface to connect the PHYs for 2 GEMs. -Joe _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot