Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Message-ID: <4ece4a98-ff35-6a95-6f06-cbb9eaa50e8c@axentia.se>
Date:   Tue, 17 Oct 2023 22:32:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [PATCH v2 2/2] i2c: mv64xxx: add an optional reset-gpios property
Content-Language: sv-SE, en-US
To:     Chris Packham <chris.packham@alliedtelesis.co.nz>,
        gregory.clement@bootlin.com, andi.shyti@kernel.org,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        conor+dt@kernel.org
Cc:     linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20231016023504.3976746-1-chris.packham@alliedtelesis.co.nz>
 <20231016023504.3976746-3-chris.packham@alliedtelesis.co.nz>
From:   Peter Rosin <peda@axentia.se>
In-Reply-To: <20231016023504.3976746-3-chris.packham@alliedtelesis.co.nz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VzlSVnVZSDNTVzZWTTdpZzRGT2dFMkdOLzlCeUt2TmFYR0llWFNxayt4amxB?=
 =?utf-8?B?cGl2d2xCQkVWeUEyVHJZZUxibXlxejRVWTBqWXEwYXp0S2U2S0EwWTVmQkJ1?=
 =?utf-8?B?TE8xRGgrb1J4TDRRS0ZOdk5xTFFUeFRTckE1OTA3N1JtVkdzWWVHTWVoSG9u?=
 =?utf-8?B?U3NIZ2RkMXJGSEhobVEvdjltazYzdE5XMy9oc0tKZGo2bWM3TzF4SzlzVHBU?=
 =?utf-8?B?MkJTYmlMMVIzM3ExWldnRFltUzAvMTdrNWpSUGFrSzdKUUZwbG1uZHRNOERX?=
 =?utf-8?B?OHYwUFRSRmttWGFmYzQzWTJaNk4zU0VKNm4wSDRONlBraS9FbGQwcEFvMEpr?=
 =?utf-8?B?U3BseENQYVdUVWpEMUkwWWxKLzF6enBaZTlSWDRyaWNmMGtnbXFWR003VkM5?=
 =?utf-8?B?c25ad3ZkTDdyc2FxWHlWNmZ3SjlPdjlCTjdDODZIQVJVSHBlRVluV0U0NDda?=
 =?utf-8?B?ck44NmpYU05jU0c1dUJjZkFlZHRZTCswYk1mVlk4OFFncXhWMzVmZGdnOFB3?=
 =?utf-8?B?WGpSOUFuc3IzNU0rMm1JRXVwWmVuTTJXRUFNZHBSakRENkZaNnhlVmFKK3Jl?=
 =?utf-8?B?Z0Vody90c01TTmJGQyt6VEVZT3VjeXFLQ3VGTHVXM2o3TUdhL3VBYldadHkz?=
 =?utf-8?B?SDJ6b0FRL2hKanVkb0JUdnVJZmhjSzhnWEZyZjZiKzJWNVhQbGdxbENnSUdu?=
 =?utf-8?B?azdKbGF1M0daSll0NjZPWDk5MUdkTVd1YnZQclFtby9kR0UrbldvYWxjQWdC?=
 =?utf-8?B?OStZOEpyZENUbm5SVnU1U2RSS2p3ZS9JU216OE9xbENVSnc1aUM5VnBDYmJM?=
 =?utf-8?B?V1ZWZTVWWCtvRyt6Y01VMTBiRTJxQndkRjZhSngvU0dNbUMrWWRKQTZ4dEp5?=
 =?utf-8?B?U3JLRjMrUG1oQzE4ZXpuL0IvNkxOc2JsOVpVTlcyTzZ1OGk3RkFHS3poeW9x?=
 =?utf-8?B?L3lZRmhFS3pIeFYzclFzcUdmSDJVQnpyOGVLYnROOEFpN2VKQ1pFVm9tT2JR?=
 =?utf-8?B?eUdlWTRqbVpRRjNCVlNJMHdBaU9LV0hYci9ZYTgycE5pV0JrYlU2NExvc1kx?=
 =?utf-8?B?NVhZL3poV2dPZEVKQ3dBblVhdXdxOEUwNEdEUFdXOExGOW5pYklvRW5xWVkz?=
 =?utf-8?B?OHdTbFJON3owUWRKSlE5dnJsMXpJQmMvVDcyZE5idGUzcXdRNHdYRFV6ZnZB?=
 =?utf-8?B?TkdlQ014KzJUWjhjOWp4M1FkQzZhOFYrY2ZxN2hjem93VEsxL0trZlRkbXBt?=
 =?utf-8?B?enRNSmJueTA2b1BKZHc0VU1wS1hvNmF1aDBGbXA5eUVNb25VaHBOcThDVE56?=
 =?utf-8?B?NHBzL0JhZjFsQ0xDL1ZtSCtVUHZXV2ZGaGY1OWMvbktjVDhFSU9Cb2lFbCtO?=
 =?utf-8?B?NHJxMFp4OU1sMXJKcytyci8xcTBUMXljRlpiR1phV1llSUl6MmhNSXpNUXNM?=
 =?utf-8?B?Q0R4WUhyNFh0NFdjREJVOTNWaEJnU0hKUWcxaEZXMjVxZWhaL3F6TkhOYWFC?=
 =?utf-8?B?ODROZFFqZTdQMXdWeU9zdUsvN0lXVUFKQy9jVTRvZVMzdXd2VnBUTnJrblNR?=
 =?utf-8?B?ZHp2ZjhkV3k0aGl4KzhJRDhPVzhMeGVEdExYU0VnK0pmSFY2dFlqcVRNeEhU?=
 =?utf-8?B?aFdjTGJId0lBL3FULzE0RlRsTEY2MEJyRTZuNHZGUk9CMXFRcHJUZ1R4cjY4?=
 =?utf-8?B?d1ZUM2lxeFA4U3JGSjh4dVRyMjhieStZTVk5ZlRBZ04vb2F6cmU0bFZTL2ha?=
 =?utf-8?B?UW9YRmJIbW1tYlNXN1U0clJVUzB1R1FuWjVTSlZaeVE2MmVFRStzeUY2eU5H?=
 =?utf-8?B?aEkwZDdOd3VkaFlrY1NFRm1BV2xZZlZ5NzZJM3d2cEtvTTVYUlU4djdWYzh2?=
 =?utf-8?B?dEJ2T0xYUGVWVzU1cTV0c1YwTGUrRzVEaHdzZjVZQk10SnNNTm5rcjlYNkdr?=
 =?utf-8?B?WmY3V01SRVVJWVl6T09oNXZWNjhnVjh5MHdvQXVidk5ZZWxzZnBTSjA5NUo2?=
 =?utf-8?B?cFdFZWxjWlFUVzNQODdkQmY5OS9ONEhHYnl4SHpYb0ZPVjk0c2hQTWczSkts?=
 =?utf-8?B?K0EvNzVIUFZGajNHSXozblYvL09DS1VwSUp0ZVhhZEY1QjBDSkpmV3NRVU5y?=
 =?utf-8?Q?1BtbjnJk5Wpt0tEVzFtzyv4UL?=
X-OriginatorOrg: axentia.se
X-MS-Exchange-CrossTenant-Network-Message-Id: c1c528ee-f66e-41b6-d23b-08dbcf5026d7
X-MS-Exchange-CrossTenant-AuthSource: AM0PR02MB4436.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2023 20:32:16.0511
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4ee68585-03e1-4785-942a-df9c1871a234
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: UfVXaIXmHIpUy47ikLZI338oPFVg3Ju2pwxHJe+P5/Zk+FvndwBEBN4eXZTU9MAn
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB5759
X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 17 Oct 2023 13:32:28 -0700 (PDT)

Hi!

2023-10-16 at 04:35, Chris Packham wrote:
> Some hardware designs have a GPIO used to control the reset of all the
> devices on and I2C bus. It's not possible for every child node to
> declare a reset-gpios property as only the first device probed would be
> able to successfully request it (the others will get -EBUSY). Represent
> this kind of hardware design by associating the reset-gpios with the
> parent I2C bus. The reset line will be released prior to the child I2C
> devices being probed.
> 
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> 
> Notes:
>     Changes in v2:
>     - Add a property to cover the length of delay after releasing the reset
>       GPIO
>     - Use dev_err_probe() when requesing the GPIO fails
> 
>  drivers/i2c/busses/i2c-mv64xxx.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
> index efd28bbecf61..50c470e5c4be 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -160,6 +160,7 @@ struct mv64xxx_i2c_data {
>  	bool			clk_n_base_0;
>  	struct i2c_bus_recovery_info	rinfo;
>  	bool			atomic;
> +	struct gpio_desc	*reset_gpio;
>  };
>  
>  static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = {
> @@ -1036,6 +1037,7 @@ mv64xxx_i2c_probe(struct platform_device *pd)
>  	struct mv64xxx_i2c_data		*drv_data;
>  	struct mv64xxx_i2c_pdata	*pdata = dev_get_platdata(&pd->dev);
>  	struct resource *res;
> +	u32	reset_udelay;
>  	int	rc;
>  
>  	if ((!pdata && !pd->dev.of_node))
> @@ -1083,6 +1085,14 @@ mv64xxx_i2c_probe(struct platform_device *pd)
>  	if (drv_data->irq < 0)
>  		return drv_data->irq;
>  
> +	drv_data->reset_gpio = devm_gpiod_get_optional(&pd->dev, "reset", GPIOD_OUT_HIGH);
> +	if (IS_ERR(drv_data->reset_gpio))
> +		return dev_err_probe(&pd->dev, PTR_ERR(drv_data->reset_gpio),
> +				     "Cannot get reset gpio\n");
> +	rc = device_property_read_u32(&pd->dev, "reset-delay-us", &reset_udelay);
> +	if (rc)
> +		reset_udelay = 1;
> +
>  	if (pdata) {
>  		drv_data->freq_m = pdata->freq_m;
>  		drv_data->freq_n = pdata->freq_n;
> @@ -1121,6 +1131,11 @@ mv64xxx_i2c_probe(struct platform_device *pd)
>  			goto exit_disable_pm;
>  	}
>  
> +	if (drv_data->reset_gpio) {
> +		gpiod_set_value_cansleep(drv_data->reset_gpio, 0);

There is no limit to how short the reset pulse will be with this
implementation. What I was requesting in my comment for v1 was
a way to control the length of the reset pulse (not the delay
after the pulse). There are devices that behave very badly if
the reset pulse is too short for their liking, others might not
react at all...

Some delay after the pulse might also be needed, of course.

Cheers,
Peter

> +		usleep_range(reset_udelay, reset_udelay + 10);
> +	}
> +
>  	rc = request_irq(drv_data->irq, mv64xxx_i2c_intr, 0,
>  			 MV64XXX_I2C_CTLR_NAME, drv_data);
>  	if (rc) {