linux-kernel - Re: [PATCH 1/2] usb: typec: tps6598x: add reset gpio support

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: <0e43362f-83c5-fcdf-f18c-5815f9d4d98f@wolfvision.net>
Date:   Fri, 15 Sep 2023 09:09:55 +0200
From:   Javier Carrasco <javier.carrasco@...fvision.net>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 1/2] usb: typec: tps6598x: add reset gpio support

Hello Krzysztof,

On 15.09.23 08:57, Krzysztof Kozlowski wrote:
> On 15/09/2023 08:50, Javier Carrasco wrote:
>> The TPS6598x PD controller provides an active-high hardware reset input
>> that reinitializes all device settings. If it is not grounded by
>> design, the driver must be able to de-assert it in order to initialize
>> the device.
>>
>> The PD controller is not ready for registration right after the reset
>> de-assertion and a delay must be introduced in that case. According to
>> TI, the delay can reach up to 1000 ms [1], which is in line with the
>> experimental results obtained with a TPS65987D.
>>
>> Add a GPIO descriptor for the reset signal and basic reset management
>> for initialization and suspend/resume.
>>
>> [1] https://e2e.ti.com/support/power-management-group/power-management/
>> f/power-management-forum/1269856/tps65987d-tps65987d-reset-de-assert-
>> to-normal-operation/4809389#4809389
>>
>> Signed-off-by: Javier Carrasco <javier.carrasco@...fvision.net>
>> ---
>>  drivers/usb/typec/tipd/core.c | 21 ++++++++++++++++++++-
>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c
>> index 37b56ce75f39..550f5913e985 100644
>> --- a/drivers/usb/typec/tipd/core.c
>> +++ b/drivers/usb/typec/tipd/core.c
>> @@ -8,6 +8,7 @@
>>  
>>  #include <linux/i2c.h>
>>  #include <linux/acpi.h>
>> +#include <linux/gpio/consumer.h>
>>  #include <linux/module.h>
>>  #include <linux/of.h>
>>  #include <linux/power_supply.h>
>> @@ -43,6 +44,9 @@
>>  /* TPS_REG_SYSTEM_CONF bits */
>>  #define TPS_SYSCONF_PORTINFO(c)		((c) & 7)
>>  
>> +/* reset de-assertion to ready for operation */
>> +#define SETUP_MS			1000
> 
> 1 second? That's a bit a lot. Does it come from datasheet?
> 
I also thought it is a long delay, but when I tested it myself with real
hardware I got values of hundreds of milliseconds until the
regmap_init_i2c was able to reach the device. I also noticed that there
is already a timeout of 1s in the tps_6598x_exec_cmd function, which
made me suspect that the timing might be a factor to consider.

The datasheet does not provide any timing for the reset, so I asked the
manufacturer (TI).
The reply form the TI technical staff was that depending on the
configuration it might take from 800 to 1000 ms. I added a link to that
answer in the commit message.

>> +
>>  enum {
>>  	TPS_PORTINFO_SINK,
>>  	TPS_PORTINFO_SINK_ACCESSORY,
>> @@ -86,6 +90,7 @@ struct tps6598x {
>>  	struct mutex lock; /* device lock */
>>  	u8 i2c_protocol:1;
>>  
>> +	struct gpio_desc *reset;
>>  	struct typec_port *port;
>>  	struct typec_partner *partner;
>>  	struct usb_pd_identity partner_identity;
>> @@ -717,6 +722,13 @@ static int tps6598x_probe(struct i2c_client *client)
>>  	mutex_init(&tps->lock);
>>  	tps->dev = &client->dev;
>>  
>> +	tps->reset = devm_gpiod_get_optional(tps->dev, "reset", GPIOD_OUT_LOW);
>> +	if (IS_ERR(tps->reset))
>> +		return dev_err_probe(tps->dev, PTR_ERR(tps->reset),
>> +				     "failed to get reset GPIO\n");
>> +	if (tps->reset)
>> +		msleep(SETUP_MS);
>> +
>>  	tps->regmap = devm_regmap_init_i2c(client, &tps6598x_regmap_config);
>>  	if (IS_ERR(tps->regmap))
>>  		return PTR_ERR(tps->regmap);
>> @@ -892,6 +904,9 @@ static void tps6598x_remove(struct i2c_client *client)
>>  	tps6598x_disconnect(tps, 0);
>>  	typec_unregister_port(tps->port);
>>  	usb_role_switch_put(tps->role_sw);
>> +
>> +	if (tps->reset)
>> +		gpiod_set_value_cansleep(tps->reset, 1);
>>  }
>>  
>>  static int __maybe_unused tps6598x_suspend(struct device *dev)
>> @@ -902,7 +917,8 @@ static int __maybe_unused tps6598x_suspend(struct device *dev)
>>  	if (tps->wakeup) {
>>  		disable_irq(client->irq);
>>  		enable_irq_wake(client->irq);
>> -	}
>> +	} else if (tps->reset)
>> +		gpiod_set_value_cansleep(tps->reset, 1);
> 
> Missing {} (see Linux coding style).
> 
Thanks, I will correct this for v2.
>>  
>>  	if (!client->irq)
>>  		cancel_delayed_work_sync(&tps->wq_poll);
>> @@ -918,6 +934,9 @@ static int __maybe_unused tps6598x_resume(struct device *dev)
>>  	if (tps->wakeup) {
>>  		disable_irq_wake(client->irq);
>>  		enable_irq(client->irq);
>> +	} else if (tps->reset) {
>> +		gpiod_set_value_cansleep(tps->reset, 0);
>> +		msleep(SETUP_MS);
>>  	}
>>  
>>  	if (!client->irq)
>>
> 
> Best regards,
> Krzysztof
> 
Best regards,
Javier Carrasco