netdev - Re: [PATCH net-next 2/2] net: pse-pd: tps23881: support reset-gpios

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZsUGbsnkvCr_tyqS@p620>
Date: Tue, 20 Aug 2024 21:11:22 +0000
From: Kyle Swenson <kyle.swenson@....tech>
To: Oleksij Rempel <o.rempel@...gutronix.de>
CC: "kory.maincent@...tlin.com" <kory.maincent@...tlin.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>, "robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "thomas.petazzoni@...tlin.com"
	<thomas.petazzoni@...tlin.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>
Subject: Re: [PATCH net-next 2/2] net: pse-pd: tps23881: support reset-gpios

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 <kyle.swenson@....tech>
> > > ---
> > >  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 <linux/bitfield.h>
> > >  #include <linux/delay.h>
> > >  #include <linux/firmware.h>
> > > +#include <linux/gpio/consumer.h>
> > >  #include <linux/i2c.h>
> > >  #include <linux/module.h>
> > >  #include <linux/of.h>
> > >  #include <linux/platform_device.h>
> > >  #include <linux/pse-pd/pse.h>
> > > -
> > 
> > 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?
> 
> > 
> > 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 |
> 
> Thanks again for the review!
> 
> Cheers,
> Kyle