public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@amd.com>
To: <carsten.haitzler@foss.arm.com>, <michal.simek@xilinx.com>,
	<shubhrajyoti.datta@xilinx.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-i2c@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	'Wolfram Sang' <wsa@kernel.org>
Subject: Re: [PATCH v2] i2c: cadence: Fix regression with bus recovery
Date: Mon, 28 Nov 2022 11:59:14 +0100	[thread overview]
Message-ID: <a885977a-bfdf-fe1c-8f33-732b18f5abec@amd.com> (raw)
In-Reply-To: <20221128105158.1536551-1-carsten.haitzler@foss.arm.com>

+Wolfram,

On 11/28/22 11:51, carsten.haitzler@foss.arm.com wrote:
> CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
> 
> 
> From: Carsten Haitzler <carsten.haitzler@arm.com>
> 
> Commit "i2c: cadence: Add standard bus recovery support" breaks for i2c
> devices that have no pinctrl defined. There is no requirement for this
> to exist in the DT. This has worked perfectly well without this before in
> at least 1 real usage case on hardware (Mali Komeda DPU, Cadence i2c to
> talk to a tda99xx phy). Adding the requirement to have pinctrl set up in
> the device tree (or otherwise be found) is a regression where the whole
> i2c device is lost entirely (in this case dropping entire devices which
> then leads to the drm display stack unable to find the phy for display
> output, thus having no drm display device and so on down the chain).
> 
> This converts the above commit to an enhancement if pinctrl can be found
> for the i2c device, providing a timeout on read with recovery, but if not,
> do what used to be done rather than a fatal loss of a device.
> 
> This restores the mentioned display devices to their working state again.
> 
> Fixes: 58b924241d0a ("i2c: cadence: Add standard bus recovery support")
> Signed-off-by: Carsten Haitzler <carsten.haitzler@arm.com>
> ---
> Note: This issue was discovered during the porting of the linux kernel
> on Morello [1].
> 
> [1] https://git.morello-project.org/morello/kernel/linux
> ---
>   drivers/i2c/busses/i2c-cadence.c | 12 ++++++++----
>   1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
> index fe0cd205502d..09acd2d399d5 100644
> --- a/drivers/i2c/busses/i2c-cadence.c
> +++ b/drivers/i2c/busses/i2c-cadence.c
> @@ -852,7 +852,8 @@ static int cdns_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
>                                           CDNS_I2C_POLL_US, CDNS_I2C_TIMEOUT_US);
>          if (ret) {
>                  ret = -EAGAIN;
> -               i2c_recover_bus(adap);
> +               if (id->adap.bus_recovery_info)
> +                       i2c_recover_bus(adap);
>                  goto out;
>          }
> 
> @@ -1263,9 +1264,13 @@ static int cdns_i2c_probe(struct platform_device *pdev)
> 
>          id->rinfo.pinctrl = devm_pinctrl_get(&pdev->dev);
>          if (IS_ERR(id->rinfo.pinctrl)) {
> +               int err = PTR_ERR(id->rinfo.pinctrl);
> +
>                  dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
> -               return PTR_ERR(id->rinfo.pinctrl);
> -       }
> +               if (err != -ENODEV)
> +                       return err;
> +       } else
> +               id->adap.bus_recovery_info = &id->rinfo;
> 
>          id->membase = devm_platform_get_and_ioremap_resource(pdev, 0, &r_mem);
>          if (IS_ERR(id->membase))
> @@ -1283,7 +1288,6 @@ static int cdns_i2c_probe(struct platform_device *pdev)
>          id->adap.retries = 3;           /* Default retry value. */
>          id->adap.algo_data = id;
>          id->adap.dev.parent = &pdev->dev;
> -       id->adap.bus_recovery_info = &id->rinfo;
>          init_completion(&id->xfer_done);
>          snprintf(id->adap.name, sizeof(id->adap.name),
>                   "Cadence I2C at %08lx", (unsigned long)r_mem->start);
> --
> 2.32.0
> 

Acked-by: Michal Simek <michal.simek@amd.com>

Wolfram: up2you if you want to take it for 6.1. If it is too late I think it 
should be labeled as stable material for 6.1.

Thanks,
Michal

  parent reply	other threads:[~2022-11-28 10:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 10:51 [PATCH v2] i2c: cadence: Fix regression with bus recovery carsten.haitzler
2022-11-28 10:54 ` Datta, Shubhrajyoti
2022-11-28 10:59 ` Michal Simek [this message]
2022-12-01 22:42 ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a885977a-bfdf-fe1c-8f33-732b18f5abec@amd.com \
    --to=michal.simek@amd.com \
    --cc=carsten.haitzler@foss.arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@xilinx.com \
    --cc=shubhrajyoti.datta@xilinx.com \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox