[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <o3c4fxt5xtabsgdg6oz4qyy6rvc7l5qojl65hvd2x2zxyz34bn@7vjv6obs6rgk>
Date: Wed, 20 Dec 2023 15:50:55 +0000
From: Alvin Šipraga <ALSI@...g-olufsen.dk>
To: Luiz Angelo Daros de Luca <luizluca@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>, "andrew@...n.ch"
<andrew@...n.ch>, "f.fainelli@...il.com" <f.fainelli@...il.com>,
"olteanv@...il.com" <olteanv@...il.com>, "davem@...emloft.net"
<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
"arinc.unal@...nc9.com" <arinc.unal@...nc9.com>
Subject: Re: [PATCH net-next v2 3/7] net: dsa: realtek: common realtek-dsa
module
On Wed, Dec 20, 2023 at 10:40:25AM +0000, Alvin Šipraga wrote:
> On Wed, Dec 20, 2023 at 01:24:26AM -0300, Luiz Angelo Daros de Luca wrote:
> > + /* TODO: if power is software controlled, set up any regulators here */
> > +
> > + priv->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> > + if (IS_ERR(priv->reset)) {
> > + dev_err(dev, "failed to get RESET GPIO\n");
> > + return ERR_CAST(priv->reset);
> > + }
> > + if (priv->reset) {
> > + gpiod_set_value(priv->reset, 1);
> > + dev_dbg(dev, "asserted RESET\n");
> > + msleep(REALTEK_HW_STOP_DELAY);
> > + gpiod_set_value(priv->reset, 0);
> > + msleep(REALTEK_HW_START_DELAY);
> > + dev_dbg(dev, "deasserted RESET\n");
> > + }
>
> I simply cannot understand why you insist on moving this part despite
> our earlier discussion on it where I pointed out that it makes no
> sense to move it. Is chip hardware reset not the discipline of the chip
> variant driver?
>
> Why don't you just keep it in its original place? It will make your
> patch smaller, which is what you seemed to care about the last time I
> raised this.
>
> Sorry, but I cannot give my Reviewed-by on this patch with this part
> moved around.
Well, to be fair, your original goal was to add support for reset
controllers. And Vladimir pointed out that you end up with a lot of
duplicated code when doing that. And he has a point.
So on reflection, I think this part is OK for now. Then you can then get
unblocked and put your reset controller patch on top when you get around
to it, without the code duplication. I think code can be adapted to
support regulators without too much churn. I'm sorry for the overly
negative feedback.
But please have a look at my comments in patch 5, since they apply more
broadly to your series.
Kind regards,
Alvin
Powered by blists - more mailing lists