From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DD30245016 for ; Wed, 21 Aug 2024 04:45:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724215553; cv=none; b=SqZGcrFtqg/OtksbAbGag2CSP5lDWOlY/ihgBFBcHBPA33OZ9TNoxvNN5EC6I3ukTU7OZmZQMB8KIjOyQOP/bIoJHcS5CORJCdps7XMyZrkGJ+C41ofAkJFL6Wku1n9x/daPPsEdGo9R/ilwKPgZT+o4c/agPVuJ4WDfsIjXM+w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724215553; c=relaxed/simple; bh=jZz3LWN68RnPgIUqgxrVPxpg+fdNLalxNbimRc3RCE0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PQbn+MOfcErw5H9E+rksBdH1/KhTCnlLp+1OCGvflZ0+9HQLjR0QzVARbZ2GPooO9UYF0MJBmDwPPxKEvwqilGQrXeCuSR2q+kfYdGxz76BlnPcS1sIS9HWnpJ7NJnbg3XD83Hc0ORMsY5H/qoIqvb4zVAmLBNY3E5G/cFq7kH8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sgdDu-00077x-HS; Wed, 21 Aug 2024 06:45:30 +0200 Received: from [2a0a:edc0:2:b01:1d::c5] (helo=pty.whiteo.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sgdDs-001vi2-ME; Wed, 21 Aug 2024 06:45:28 +0200 Received: from ore by pty.whiteo.stw.pengutronix.de with local (Exim 4.96) (envelope-from ) id 1sgdDs-00FNkZ-1l; Wed, 21 Aug 2024 06:45:28 +0200 Date: Wed, 21 Aug 2024 06:45:28 +0200 From: Oleksij Rempel To: Kyle Swenson Cc: "kory.maincent@bootlin.com" , "davem@davemloft.net" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "robh@kernel.org" , "krzk+dt@kernel.org" , "conor+dt@kernel.org" , "thomas.petazzoni@bootlin.com" , "netdev@vger.kernel.org" , "devicetree@vger.kernel.org" Subject: Re: [PATCH net-next 2/2] net: pse-pd: tps23881: support reset-gpios Message-ID: References: <20240819190151.93253-1-kyle.swenson@est.tech> <20240819190151.93253-3-kyle.swenson@est.tech> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ore@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: devicetree@vger.kernel.org Hi Kyle, On Tue, Aug 20, 2024 at 09:11:22PM +0000, Kyle Swenson wrote: > On Tue, Aug 20, 2024 at 03:06:19PM -0600, Kyle Swenson wrote: > > Hi Oleksij, > > > > On Tue, Aug 20, 2024 at 08:23:58AM +0200, Oleksij Rempel wrote: > > > Hi Kyle, > > > > > > thank you for you patch. > > Thanks for the review! > > > > > > On Mon, Aug 19, 2024 at 07:02:14PM +0000, Kyle Swenson wrote: > > > > The TPS23880/1 has an active-low reset pin that some boards connect to > > > > the SoC to control when the TPS23880 is pulled out of reset. > > > > > > > > Add support for this via a reset-gpios property in the DTS. > > > > > > > > Signed-off-by: Kyle Swenson > > > > --- > > > > drivers/net/pse-pd/tps23881.c | 13 ++++++++++++- > > > > 1 file changed, 12 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/net/pse-pd/tps23881.c b/drivers/net/pse-pd/tps23881.c > > > > index 2ea75686a319..837e1a2119ee 100644 > > > > --- a/drivers/net/pse-pd/tps23881.c > > > > +++ b/drivers/net/pse-pd/tps23881.c > > > > @@ -6,16 +6,16 @@ > > > > */ > > > > > > > > #include > > > > #include > > > > #include > > > > +#include > > > > #include > > > > #include > > > > #include > > > > #include > > > > #include > > > > - > > > > > > No need to remove space here. > > > > Sorry about this, somehow I missed this gratuitous diff > > > > > > > > > #define TPS23881_MAX_CHANS 8 > > > > > > > > #define TPS23881_REG_PW_STATUS 0x10 > > > > #define TPS23881_REG_OP_MODE 0x12 > > > > #define TPS23881_OP_MODE_SEMIAUTO 0xaaaa > > > > @@ -735,10 +735,11 @@ static int tps23881_flash_sram_fw(struct i2c_client *client) > > > > > > > > static int tps23881_i2c_probe(struct i2c_client *client) > > > > { > > > > struct device *dev = &client->dev; > > > > struct tps23881_priv *priv; > > > > + struct gpio_desc *reset; > > > > int ret; > > > > u8 val; > > > > > > > > if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) { > > > > dev_err(dev, "i2c check functionality failed\n"); > > > > @@ -747,10 +748,20 @@ static int tps23881_i2c_probe(struct i2c_client *client) > > > > > > > > priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); > > > > if (!priv) > > > > return -ENOMEM; > > > > > > > > + reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); > > > > + if (IS_ERR(reset)) > > > > + return dev_err_probe(&client->dev, PTR_ERR(reset), "Failed to get reset GPIO\n"); > > > > + > > > > + if (reset) { > > > > + usleep_range(1000, 10000); > > > > + gpiod_set_value_cansleep(reset, 0); /* De-assert reset */ > > > > + usleep_range(1000, 10000); > > > > > > According to the datasheet, page 13: > > > https://www.ti.com/lit/ds/symlink/tps23880.pdf > > > > > > Minimal reset time is 5 microseconds and the delay after power on reset should > > > be at least 20 milliseconds. Both sleep values should be corrected. > > > > Sounds reasonable, I'll change the first delay to be closer to the 5us > > minimum reset time. I need to review the docs around delays to pick the > > correct one for this case. > > > > For the 2nd delay, I (now) see the 20ms you're referring to in the datasheet. > > > > I was looking at the SRAM programming document > > (https://www.ti.com/lit/pdf/SLVAE1) and it indicates we should delay the > > Sorry, this is the wrong link. Let me try again: > > https://www.ti.com/lit/pdf/slvae12 > > > > SRAM and parity programming by at least 50ms after initial power on. > > > > Should we guarantee we meet that 50ms requirement with the 2nd delay or > > would you prefer I just meet the 20ms requirement in the datasheet? Ah, I see. The easiest way would be to wait 50ms, otherwise we will need to do some more code to get this 50ms requirement. Please add comments to the code describing the reason for one or another delay. And, please use name and revision of documentation you used for this choice. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |