[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65e4c9936f95a23ad56498ac198fd4df35eb8fd6.camel@pengutronix.de>
Date: Fri, 26 Nov 2021 11:19:05 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Horatiu Vultur <horatiu.vultur@...rochip.com>, davem@...emloft.net,
kuba@...nel.org, robh+dt@...nel.org, UNGLinuxDriver@...rochip.com,
linux@...linux.org.uk, andrew@...n.ch, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v4 2/6] net: lan966x: add the basic lan966x
driver
Hi Horatiu,
On Fri, 2021-11-26 at 10:05 +0100, Horatiu Vultur wrote:
[...]
> +static int lan966x_reset_switch(struct lan966x *lan966x)
> +{
> + struct reset_control *reset;
> + int val = 0;
> + int ret;
> +
> + reset = devm_reset_control_get_shared(lan966x->dev, "switch");
> + if (IS_ERR(reset))
> + return dev_err_probe(lan966x->dev, PTR_ERR(reset),
> + "Could not obtain switch reset");
> + reset_control_reset(reset);
> +
> + reset = devm_reset_control_get_shared(lan966x->dev, "phy");
> + if (IS_ERR(reset))
> + return dev_err_probe(lan966x->dev, PTR_ERR(reset),
> + "Could not obtain phy reset\n");
> + reset_control_reset(reset);
In general, please request all resources before activating the hardware.
Here I'd request both reset controls first and only then trigger them.
That way a failure to optain the phy reset won't cause an unnecessary
switch reset.
[...]
> +static int lan966x_remove(struct platform_device *pdev)
> +{
> + return 0;
> +}
If there is nothing to do here, this function can be removed altogether.
regards
Philipp
Powered by blists - more mailing lists