Re: [PATCH v3 2/9] net: arc_emac: add phy reset is optional for device tree

[Caesar Wang]

Hi Sergei,

å 2016å03æ16æ 21:57, Sergei Shtylyov åé:
> Hello.
>
> On 3/14/2016 11:01 AM, Caesar Wang wrote:
>
> > This patch adds the following property for arc_emac.
> >
> > 1) phy-reset-gpios:
> > The phy-reset-gpio is an optional property for arc emac device tree 
> > boot.
> > Change the binding document to match the driver code.
> >
> > 2) phy-reset-duration:
> > Different boards may require different phy reset duration. Add property
> > phy-reset-duration for device tree probe, so that the boards that need
> > a longer reset duration can specify it in their device tree.
> >
> > Anyway, we can add the above property for arc emac.
> >
> > Signed-off-by: Caesar Wang <wxt@xxxxxxxxxxxxxx>
>
>   Could you have a look at drivers/net/ethernet/cadence/macb/? It 
> seems to be the only driver which places the PHY's "reset-gpios" prop 
> correctly, into the PHY subnode? I'm currently working on adding 
> support of this prop into phylib...

I see the driver on now.


    /* Power up the PHY if there is a GPIO reset */
    phy_node =  of_get_next_available_child(np, NULL);
    if (phy_node) {
        int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0);
        if (gpio_is_valid(gpio))
            bp->reset_gpio = gpio_to_desc(gpio);
        gpiod_set_value(bp->reset_gpio, GPIOD_OUT_HIGH);
    }
    of_node_put(phy_node);
...

Frankly, I don't like this way in device drivers.
That's seem same with the /drivers/mmc/core/pwrseq_simple.c,  power up 
the device.
Is it not really reset hardware PHY from the gpio reset pin?  Just power up.

Of course, I hope to see and test it if you improve the PHY framework to 
support the phy reset.:-)

---

Anyway,  David had applied this series patches into net branch.

Although the clock and dts patches should be applied into Heiko branch,  
I'm glad to see David's way.

Heiko branch:
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/


I wish won't destory Heiko to merge in the future.


-Caesar



> MBR, Sergei
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-rockchip


--
Thanks,
Caesar