On Sun, Feb 7, 2021 at 10:32 PM Samuel Holland <sam...@sholland.org> wrote:
>
> Use the appropriate function instead of reimplementing it,
> and update the error message to match the code.
>
> Reviewed-by: Chen-Yu Tsai <w...@csie.org>
> Signed-off-by: Samuel Holland <sam...@sholland.org>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> index 3c3d0b99d3e8..0e8d88417251 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> @@ -806,11 +806,9 @@ static int sun8i_dwmac_power_internal_phy(struct
> stmmac_priv *priv)
> /* Make sure the EPHY is properly reseted, as U-Boot may leave
> * it at deasserted state, and thus it may fail to reset EMAC.
> */
> - reset_control_assert(gmac->rst_ephy);
> -
> - ret = reset_control_deassert(gmac->rst_ephy);
> + ret = reset_control_reset(gmac->rst_ephy);
> if (ret) {
> - dev_err(priv->device, "Cannot deassert internal phy\n");
> + dev_err(priv->device, "Cannot reset internal PHY\n");
> clk_disable_unprepare(gmac->ephy_clk);
> return ret;
> }
I'm assuming you have exclusive access to the phy and this isn't a
shared line? Just wanting to confirm since the function call has the
following comment in the header for the documentation.
* Consumers must not use reset_control_(de)assert on shared reset lines when
* reset_control_reset has been used.
*
If that is the case it might not hurt to add some documentation to
your call to reset_control_reset here explaining that it is safe to do
so since you have exclusive access.
