Message-ID: <113503c8-a871-1dc0-daea-48631e1a436d@arf.net.pl>
Date:   Sat, 29 Aug 2020 10:15:24 +0200
From:   Adam Rudziński <adam.rudzinski@....net.pl>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>
Cc:     robh+dt@...nel.org, frowand.list@...il.com
Subject: Re: drivers/of/of_mdio.c needs a small modification

W dniu 2020-08-29 o 05:29, Florian Fainelli pisze:
>
> On 8/28/2020 4:14 PM, Adam Rudziński wrote:
>> W dniu 2020-08-29 o 00:53, Andrew Lunn pisze:
>>> On Sat, Aug 29, 2020 at 12:34:05AM +0200, Adam Rudziński wrote:
>>>> Hi Andrew.
>>>>
>>>> W dniu 2020-08-29 o 00:28, Andrew Lunn pisze:
>>>>> Hi Adam
>>>>>
>>>>>> If kernel has to bring up two Ethernet interfaces, the processor 
>>>>>> has two
>>>>>> peripherals with functionality of MACs (in i.MX6ULL these are 
>>>>>> Fast Ethernet
>>>>>> Controllers, FECs), but uses a shared MDIO bus, then the kernel 
>>>>>> first probes
>>>>>> one MAC, enables clock for its PHY, probes MDIO bus tryng to 
>>>>>> discover _all_
>>>>>> PHYs, and then probes the second MAC, and enables clock for its 
>>>>>> PHY. The
>>>>>> result is that the second PHY is still inactive during PHY 
>>>>>> discovery. Thus,
>>>>>> one Ethernet interface is not functional.
>>>>> What clock are you talking about? Do you have the FEC feeding a 50MHz
>>>>> clock to the PHY? Each FEC providing its own clock to its own PHY? 
>>>>> And
>>>>> are you saying a PHY without its reference clock does not respond to
>>>>> MDIO reads and hence the second PHY does not probe because it has no
>>>>> reference clock?
>>>>>
>>>>>       Andrew
>>>> Yes, exactly. In my case the PHYs are LAN8720A, and it works this way.
>>> O.K. Boards i've seen like this have both PHYs driver from the first
>>> MAC. Or the clock goes the other way, the PHY has a crystal and it
>>> feeds the FEC.
>>>
>>> I would say the correct way to solve this is to make the FEC a clock
>>> provider. It should register its clocks with the common clock
>>> framework. The MDIO bus can then request the clock from the second FEC
>>> before it scans the bus. Or we add the clock to the PHY node so it
>>> enables the clock before probing it. There are people who want this
>>> sort of framework code, to be able to support a GPIO reset, which
>>> needs releasing before probing the bus for the PHY.
>>>
>>> Anyway, post your patch, so we get a better idea what you are
>>> proposing.
>>>
>>>     Andrew
>>
>> Hm, this sounds reasonable, but complicated at the same time. I have 
>> spent some time searching for possible solution and never found 
>> anything teaching something similar, so I'd also speculate that it's 
>> kind of not very well documented. That doesn't mean I'm against these 
>> solutions, just that seems to be beyond capabilities of many mortals 
>> who even try to read.
>>
>> OK, so a patch it is. Please, let me know how to make the patch so 
>> that it was useful and as convenient as possible for you. Would you 
>> like me to use some specific code/repo/branch/... as its base?
>
> This is targeting the net-next tree, see the netdev-FAQ here for details:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.rst 
>
>
> I will be posting some patches for our ARCH_BRCMSTB platforms which 
> require that we turn on the internal PHY's digital clock otherwise it 
> does not respond on the MDIO bus and we cannot discover its ID and we 
> cannot bind to a PHY driver. I will make sure to copy you so you can 
> see if this would work for you.

Actually, I came to conclusion, that sending a patch for discussion is 
not the best idea at this time, because the original code for my kernel 
was from here:

https://github.com/SoMLabs/somlabs-linux-imx/tree/imx_4.19.35_1.1.0
commit ef35d67fb

and although it still looks similar in the kernel, I've assumed that now 
the safest way is to just attach the original and modified files. So 
here they go, with some discussion below. I hope this doesn't make a 
mess and is still good.


The essential general modification is in

drivers/of/of_mdio.c
include/linux/of_mdio.h

and to make the driver profit on that, target-specific (well, the driver 
is target-specific) modification in

drivers/net/ethernet/freescale/fec_main.c


Modification in of_mdio.c

"Original" function of_mdiobus_register contains a loop over all child 
nodes.

/**
  * of_mdiobus_register - Register mii_bus and create PHYs from the 
device tree
  * @mdio: pointer to mii_bus structure
  * @np: pointer to device_node of MDIO bus.
  *
  * This function registers the mii_bus structure and registers a phy_device
  * for each child node of @np.
  */
int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
{
(...)
         /* Register the MDIO bus */
         rc = mdiobus_register(mdio);
         if (rc)
                 return rc;

         /* Loop over the child nodes and register a phy_device for each 
phy */
         for_each_available_child_of_node(np, child) {
                 addr = of_mdio_parse_addr(&mdio->dev, child);
                 if (addr < 0) {
                         scanphys = true;
                         continue;
                 }

                 if (of_mdiobus_child_is_phy(child))
                         rc = of_mdiobus_register_phy(mdio, child, addr);
                 else
                         rc = of_mdiobus_register_device(mdio, child, addr);

                 if (rc == -ENODEV)
                         dev_err(&mdio->dev,
                                 "MDIO device at address %d is missing.\n",
                                 addr);
                 else if (rc)
                         goto unregister;
         }

         if (!scanphys)
                 return 0;
(...)
}

The loop is preceeded by mdiobus_register, so this provides service only 
for a new MDIO bus. It is not possible to later add more child nodes. 
Therefore the driver has to know all the child nodes before it registers 
the bus. The device tree looks more or less like this:

&fec2 {
(...)
     mdio {
         (all PHYs here)
     };
(...)
};

&fec1 {
    (some stuff, but no mdio here)
};

The driver (fec_main.c) for the second FEC has to only set the pointer 
to the shared MDIO bus, but also cannot do anything more:

         if ((fep->quirks & FEC_QUIRK_SINGLE_MDIO) && fep->dev_id > 0) {
                 /* fec1 uses fec0 mii_bus */
                 if (mii_cnt && fec0_mii_bus) {
                         fep->mii_bus = fec0_mii_bus;
                         *fec_mii_bus_share = FEC0_MII_BUS_SHARE_TRUE;
                         mii_cnt++;
                         return 0;
                 }
                 return -ENOENT;
         }

I propose to get the loop out of of_mdiobus_register and make it a new 
public function (with prototype in of_mdio.h; most likely it makes sense 
to add checking if pointers are not NULL).

/**
  * of_mdiobus_register - Register mii_bus and create PHYs from the 
device tree
  * @mdio: pointer to mii_bus structure
  * @np: pointer to device_node of MDIO bus.
  *
  * This function registers the mii_bus structure and registers a phy_device
  * for each child node of @np.
  */
int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
{
(...)
         rc = mdiobus_register(mdio);
         if (rc)
                 return rc;

         rc = of_mdiobus_register_children(mdio, np, &scanphys);
         if (rc)
                 goto unregister;

         if (!scanphys)
                 return 0;
(...)
}

/**
  * of_mdiobus_register_children - Create PHYs from the device tree
  * @mdio: pointer to mii_bus structure
  * @np: pointer to device_node of MDIO bus.
  * @scanphys: pointer to boolean variable telling if PHYs with
  *            empty reg property should be scanned by the calling function
  *            or NULL if this is information is not needed
  *
  * This function registers a phy_device for each child node of @np.
  */
int of_mdiobus_register_children(struct mii_bus *mdio, struct 
device_node *np, bool *scanphys)
{
         struct device_node *child;
         int addr, rc;

         /* Loop over the child nodes and register a phy_device for each 
phy */
         for_each_available_child_of_node(np, child) {
                 addr = of_mdio_parse_addr(&mdio->dev, child);
                 if (addr < 0) {
                         if (scanphys) { *scanphys = true; }
                         continue;
                 }

                 if (of_mdiobus_child_is_phy(child))
                         rc = of_mdiobus_register_phy(mdio, child, addr);
                 else
                         rc = of_mdiobus_register_device(mdio, child, addr);
                 if (rc == -ENODEV)
                         dev_err(&mdio->dev,
                                 "MDIO device at address %d is missing.\n",
                                 addr);
                 else if (rc)
                         return rc;
         }

         return 0;
}

The driver would be able to add the new PHYs to the shared MDIO bus by 
calling of_mdiobus_register_children. Then the device tree looks like 
this, which is more reasonable in my opinion:

&fec2 {
(...)
     mdio {
         (phy for fec2 here)
     };
(...)
};

&fec1 {
(...)
     mdio {
         (phy for fec1 here)
     };
(...)
};

The driver would be able to add the new PHYs to the shared MDIO bus by 
calling of_mdiobus_register_children.

         if ((fep->quirks & FEC_QUIRK_SINGLE_MDIO) && fep->dev_id > 0) {
                 /* fec1 uses fec0 mii_bus */
                 if (mii_cnt && fec0_mii_bus) {
                         fep->mii_bus = fec0_mii_bus;
                         *fec_mii_bus_share = FEC0_MII_BUS_SHARE_TRUE;
                         mii_cnt++;
                         node = of_get_child_by_name(pdev->dev.of_node, 
"mdio");
                         return 
of_mdiobus_register_children(fep->mii_bus, node, NULL);
                 }
                 return -ENOENT;
         }

This could be also done later "dynamically" on runtime.

Best regards,
Adam


Download attachment "original.tar.bz2" of type "application/octet-stream" (27747 bytes)

Download attachment "proposed.tar.bz2" of type "application/octet-stream" (27900 bytes)

Powered by blists - more mailing lists