Received: by 2002:a05:7412:b10a:b0:f3:1519:9f41 with SMTP id az10csp2168471rdb; Sun, 3 Dec 2023 05:37:54 -0800 (PST) X-Google-Smtp-Source: AGHT+IG1S4+g1zghOtnqwiTImIr6wRNzVP90bEBbWw1Ng85VmuI8iHahxf0eyT4k3+xBp2yrIttV X-Received: by 2002:a92:c247:0:b0:35d:591f:861 with SMTP id k7-20020a92c247000000b0035d591f0861mr4502824ilo.8.1701610673973; Sun, 03 Dec 2023 05:37:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701610673; cv=none; d=google.com; s=arc-20160816; b=xgSHLaxoY2T/0WvQRXaLaYc3954XXQYTnk8cnu1npdGTwuFQjYIUBJaj4RCuWQr5Kb uw47KDPmaa1CxgK9av2XYwQWgtPd2N8dzHitC8Ivr2jknNNGxjaGGkEhv+UaEGscrJvq lJ+H4hmdS31zwvy+TcMy20iRMRBDdgF3RC9RWTeDvuw2pqc8p0AKA1UO6mq+Wjt92No6 oF2g+O6gmpvsnXcm3Y3EVFF5jG34eJ7m5mnR6HyuMB5xFeWy0QoADzKKhIAyhIyVvgQl uARRtyZQMK2RckddJyKMbgdzARR+iTc7F1KXRPZeFzxUrNli4VKcjmzGtqe0V+KNnXCN Nepg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=IqnEErrukRa1U5jJew7ay6KSJWwcb+PijXW2An2yRNM=; fh=kSZSpifhwOEwwEIiu760wFQYXIdILBsXdvs+rw9LmKk=; b=goCXiwtTqWe1Oa5s4fI+zl/9ywGYnorP59qRpSn1kgYqHGakbf+ks/ygnvgc1WQWfe sZq6UnkVlYDm5oNhPRjJoF5heZ9th150uy6vN2/mZZBB5FAf0gvwmbNlP+PLIBVU5TZS 2vQIOde4ueqwk3kc8ZRIb4dKcsN2PbAGdIDTFeW/kdWYaR1jGcdrzqOknVsRsod54dKD hZC66EpNWt8n+ky0uAWcNhJ6VVm6Sj0UuUkGyzP6kwRk4lHT5XFx9pVgV/4+ETkbmkDc ykCgKCVI6irbWn1G23pAPYnzN7qRgtjVroiAUTz95MY5xxBsQS6qFCKlOn8QXEn0hv3V Pj6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JjxMu+Q7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id f23-20020a63f117000000b0059779ae5899si6415090pgi.836.2023.12.03.05.37.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 Dec 2023 05:37:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=JjxMu+Q7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id F042980859B9; Sun, 3 Dec 2023 05:37:50 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233386AbjLCNhc (ORCPT + 99 others); Sun, 3 Dec 2023 08:37:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229450AbjLCNhb (ORCPT ); Sun, 3 Dec 2023 08:37:31 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F371CE7 for ; Sun, 3 Dec 2023 05:37:37 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2935BC433C7; Sun, 3 Dec 2023 13:37:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701610657; bh=g6VF/OawWYAUDmEECQlX5bMPHLfMffyKwRch+Y1hphI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JjxMu+Q75WHV/aMFVXU3gJ9a2JXzUIcX82TQk84XWQKEXEGIgNhzWL4IKvetxx06d ecDoecFR9FqIAYW2tMslc4NL1GjxE0Oc5h02D7AYk7f0KoEGyVAtSczpBpCWkULln1 k3HD9MPfgGz+76fTYlKfn8qtezeMc0oo3G6NM1ONXZ1eKHX7XsKte03TfxQKhyQzeR a5tXoujlG1kxXt0Fvh3etMnOkT6gBKmnkJQ56LkNGw2k5wE73yunRH9al+NGwGWKgl 5JnZVjCA6U4TW33YSQS0w94jWQQ34OMiqt4Z1uq5KGu4CVSHnyESY+C4N+WPeNGvQI GIMQEQIVEhudw== Date: Sun, 3 Dec 2023 14:37:33 +0100 From: Andi Shyti To: Elad Nachman Cc: gregory.clement@bootlin.com, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, cyuval@marvell.com Subject: Re: [PATCH] i2c: busses: i2c-mv64xxx: fix arb-loss i2c lock Message-ID: <20231203133733.eatne2i6eycbiomi@zenone.zhora.eu> References: <20231130162522.3306136-1-enachman@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231130162522.3306136-1-enachman@marvell.com> X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Sun, 03 Dec 2023 05:37:51 -0800 (PST) Hi Elad, On Thu, Nov 30, 2023 at 06:25:22PM +0200, Elad Nachman wrote: > From: Elad Nachman > > Some i2c slaves, mainly SFPs, might cause the bus to lose arbitration > while slave is in the middle of responding. Can you be more specific about how this is happening? > The solution is to change the I2C mode from mpps to gpios, and toggle > the i2c_scl gpio to emulate bus clock toggling, so slave will finish > its transmission, driven by the manual clock toggling, and will release > the i2c bus. > > Signed-off-by: Elad Nachman > --- > drivers/i2c/busses/i2c-mv64xxx.c | 81 ++++++++++++++++++++++++++++++++ > 1 file changed, 81 insertions(+) > > diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c > index dc160cbc3155..21715f31dc29 100644 > --- a/drivers/i2c/busses/i2c-mv64xxx.c > +++ b/drivers/i2c/busses/i2c-mv64xxx.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > > #define MV64XXX_I2C_ADDR_ADDR(val) ((val & 0x7f) << 1) > #define MV64XXX_I2C_BAUD_DIV_N(val) (val & 0x7) > @@ -104,6 +105,7 @@ enum { > MV64XXX_I2C_ACTION_RCV_DATA, > MV64XXX_I2C_ACTION_RCV_DATA_STOP, > MV64XXX_I2C_ACTION_SEND_STOP, > + MV64XXX_I2C_ACTION_UNLOCK_BUS > }; > > struct mv64xxx_i2c_regs { > @@ -150,6 +152,11 @@ struct mv64xxx_i2c_data { > bool clk_n_base_0; > struct i2c_bus_recovery_info rinfo; > bool atomic; > + /* I2C mpp states & gpios needed for arbitration lost recovery */ > + int scl_gpio, sda_gpio; > + bool arb_lost_recovery_ena; mmhhh... this name here looks quite ugly, something like "soft_reset" or "clock_stretch"? > + struct pinctrl_state *i2c_mpp_state; > + struct pinctrl_state *i2c_gpio_state; > }; > > static struct mv64xxx_i2c_regs mv64xxx_i2c_regs_mv64xxx = { > @@ -318,6 +325,11 @@ mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status) > drv_data->state = MV64XXX_I2C_STATE_IDLE; > break; > > + case MV64XXX_I2C_STATUS_MAST_LOST_ARB: /*0x38*/ Please, leave a space between the comments: /* 0x38 */ > + drv_data->action = MV64XXX_I2C_ACTION_UNLOCK_BUS; > + drv_data->state = MV64XXX_I2C_STATE_IDLE; > + break; > + > case MV64XXX_I2C_STATUS_MAST_WR_ADDR_NO_ACK: /* 0x20 */ > case MV64XXX_I2C_STATUS_MAST_WR_NO_ACK: /* 30 */ > case MV64XXX_I2C_STATUS_MAST_RD_ADDR_NO_ACK: /* 48 */ > @@ -356,6 +368,9 @@ static void mv64xxx_i2c_send_start(struct mv64xxx_i2c_data *drv_data) > static void > mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data) > { > + struct pinctrl *pc; > + int i, ret; > + > switch(drv_data->action) { > case MV64XXX_I2C_ACTION_SEND_RESTART: > /* We should only get here if we have further messages */ > @@ -409,6 +424,48 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data) > drv_data->reg_base + drv_data->reg_offsets.control); > break; > > + case MV64XXX_I2C_ACTION_UNLOCK_BUS: > + for consistency, don't add a blank line here. > + if (!drv_data->arb_lost_recovery_ena) > + break; > + > + pc = devm_pinctrl_get(drv_data->adapter.dev.parent); > + if (IS_ERR(pc)) > + break; I would add here some error message > + > + /* Change i2c MPPs state to act as GPIOs: */ > + if (pinctrl_select_state(pc, drv_data->i2c_gpio_state) >= 0) { > + ret = devm_gpio_request_one(drv_data->adapter.dev.parent, > + drv_data->scl_gpio, GPIOF_DIR_OUT, NULL); > + ret |= devm_gpio_request_one(drv_data->adapter.dev.parent, > + drv_data->sda_gpio, GPIOF_DIR_OUT, NULL); mmhhh... these are requested everytime we do an UNLOCK_BUS and freed only when the driver exits. Why don't you request them in the probe()? > + if (!ret) { > + /* Toggle i2c scl (serial clock) 10 times. > + * This allows the slave that occupies > + * the bus to transmit its remaining data, > + * so it can release the i2c bus: > + */ The proper commenting style is: /* * Toggle i2c scl (serial clock) 10 times. * This allows the slave that occupies * the bus to transmit its remaining data, * so it can release the i2c bus: */ Why 10 times? What is the requested time? > + for (i = 0; i < 10; i++) { > + gpio_set_value(drv_data->scl_gpio, 1); > + mdelay(1); Please, no mdelay! > + gpio_set_value(drv_data->scl_gpio, 0); > + }; > + > + devm_gpiod_put(drv_data->adapter.dev.parent, > + gpio_to_desc(drv_data->scl_gpio)); > + devm_gpiod_put(drv_data->adapter.dev.parent, > + gpio_to_desc(drv_data->sda_gpio)); > + } > + > + /* restore i2c pin state to MPPs: */ > + pinctrl_select_state(pc, drv_data->i2c_mpp_state); > + } > + > + /* Trigger controller soft reset: */ > + writel(0x1, drv_data->reg_base + drv_data->reg_offsets.soft_reset); 0x1 stands for... ? > + mdelay(1); Please, no mdelay and if there is a need to wait explain it in a comment. I need a very strong reason for using mdelay() at this point. > + fallthrough; What is the rationale behind this fallthrough? Are we moving to get a data stop later on? > + > case MV64XXX_I2C_ACTION_RCV_DATA_STOP: > drv_data->msg->buf[drv_data->byte_posn++] = > readl(drv_data->reg_base + drv_data->reg_offsets.data); > @@ -985,6 +1042,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 pinctrl *pc; > int rc; > > if ((!pdata && !pd->dev.of_node)) > @@ -1040,6 +1098,29 @@ mv64xxx_i2c_probe(struct platform_device *pd) > if (rc == -EPROBE_DEFER) > return rc; > > + drv_data->arb_lost_recovery_ena = false; > + pc = devm_pinctrl_get(&pd->dev); > + if (!IS_ERR(pc)) { Is this optional? Please consider using "i2c-scl-clk-low-timeout-us" in the devicetree. Andi