From: rojay@codeaurora.org
To: Stephen Boyd <swboyd@chromium.org>
Cc: wsa@kernel.org, dianders@chromium.org,
saiprakash.ranjan@codeaurora.org, gregkh@linuxfoundation.org,
mka@chromium.org, akashast@codeaurora.org,
msavaliy@qti.qualcomm.com, skakit@codeaurora.org,
rnayak@codeaurora.org, agross@kernel.org,
bjorn.andersson@linaro.org, linux-arm-msm@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
sumit.semwal@linaro.org, linux-media@vger.kernel.org
Subject: Re: [PATCH V8 1/1] i2c: i2c-qcom-geni: Add shutdown callback for i2c
Date: Tue, 20 Apr 2021 16:42:13 +0530 [thread overview]
Message-ID: <30d8e3661c37c7d2580ac1f03e254680@codeaurora.org> (raw)
In-Reply-To: <161415039142.1254594.3043511127113195221@swboyd.mtv.corp.google.com>
Hi Stephen,
On 2021-02-24 12:36, Stephen Boyd wrote:
> Quoting rojay@codeaurora.org (2021-02-18 06:15:17)
>> Hi Stephen,
>>
>> On 2021-01-13 12:24, Stephen Boyd wrote:
>> > Quoting Roja Rani Yarubandi (2021-01-08 07:05:45)
>> >> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
>> >> b/drivers/i2c/busses/i2c-qcom-geni.c
>> >> index 214b4c913a13..c3f584795911 100644
>> >> --- a/drivers/i2c/busses/i2c-qcom-geni.c
>> >> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
>> >> @@ -375,6 +375,32 @@ static void geni_i2c_tx_msg_cleanup(struct
>> >> geni_i2c_dev *gi2c,
>> >> }
>> >> }
>> >>
>> >> +static void geni_i2c_stop_xfer(struct geni_i2c_dev *gi2c)
>> >> +{
>> >> + int ret;
>> >> + u32 geni_status;
>> >> + struct i2c_msg *cur;
>> >> +
>> >> + /* Resume device, as runtime suspend can happen anytime during
>> >> transfer */
>> >> + ret = pm_runtime_get_sync(gi2c->se.dev);
>> >> + if (ret < 0) {
>> >> + dev_err(gi2c->se.dev, "Failed to resume device: %d\n",
>> >> ret);
>> >> + return;
>> >> + }
>> >> +
>> >> + geni_status = readl_relaxed(gi2c->se.base + SE_GENI_STATUS);
>> >> + if (geni_status & M_GENI_CMD_ACTIVE) {
>> >> + cur = gi2c->cur;
>> >
>> > Why don't we need to hold the spinlock gi2c::lock here?
>> >
>>
>> I am not seeing any race here. May I know which race are you
>> suspecting
>> here?
>
> Sorry there are long delays between posting and replies to my review
> comments. It takes me some time to remember what we're talking about
> because this patch has dragged on for many months.
>
Sorry for the delayed responses.
> So my understanding is that gi2c::lock protects the 'cur' pointer. I
> imagine this scenario might go bad
>
> CPU0 CPU1
> ---- ----
> geni_i2c_stop_xfer()
> ... geni_i2c_rx_one_msg()
> gi2c->cur = cur1;
> cur = gi2c->cur;
> ... geni_i2c_tx_one_msg()
> gi2c->cur = cur2;
> geni_i2c_abort_xfer()
> <uses cur2>
> if (cur->flags & I2C_M_RD)
> <uses cur1 for the condition and call; oops that's bad>
>
> It's almost like we should combine the geni_i2c_abort_xfer() logic with
> the rx/tx message cleanup functions so that it's all done under one
> lock. Unfortunately it's complicated by the fact that there are various
> completion waiting timeouts involved. Fun!
>
Thanks for the explanation. Fixed this possible race by protecting
gi2c->cur
and calling geni_i2c_abort_xfer() with adding another parameter to
differentiate
from which sequence is the geni_i2c_abort_xfer() called and handle the
spin_lock/spin_unlock accordingly inside geni_i2c_abort_xfer()
> But even after all that, I don't see how the geni_i2c_stop_xfer() puts
> a
> stop to future calls to geni_i2c_rx_one_msg() or geni_i2c_tx_one_msg().
Now handled this by adding a bool variable "stop_xfer" in geni_i2c_dev
struct,
used to put stop to upcoming geni_i2c_rx_one_msg() and
geni_i2c_tx_one_msg() calls
once we receive the shutdown call.
> The hardware isn't disabled from what I can tell. The irq isn't
> disabled, the clks aren't turned off, etc. What is to stop an i2c
> device
> from trying to use the bus after this shutdown function is called? If
> anything, this function looks like a "flush", where we flush out any
> pending transfer. Where's the "plug" operation that prevents any future
> operations from following this call?
>
We are turning off clocks and disabling irq in
geni_i2c_runtime_suspend().
IIUC about shutdown sequence, during "remove" we will unplug the device
with opposite
calls to "probe's" plug operations example i2c_del_adapter(). For
"shutdown", as system
is going to shutdown, there is no need of unplug operations to be done.
> BTW, I see this is merged upstream. That's great, but it seems broken.
> Please fix it or revert it out.
>
>>
>> >> + geni_i2c_abort_xfer(gi2c);
>> >> + if (cur->flags & I2C_M_RD)
>> >> + geni_i2c_rx_msg_cleanup(gi2c, cur);
>> >> + else
>> >> + geni_i2c_tx_msg_cleanup(gi2c, cur);
>> >> + }
>> >> +
>> >> + pm_runtime_put_sync_suspend(gi2c->se.dev);
>> >> +}
>> >> +
>> >> static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct
>> >> i2c_msg *msg,
>> >> u32 m_param)
>> >> {
Thanks,
Roja
next prev parent reply other threads:[~2021-04-20 11:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 15:05 [PATCH V8 0/1] Implement Shutdown callback for geni-i2c Roja Rani Yarubandi
2021-01-08 15:05 ` [PATCH V8 1/1] i2c: i2c-qcom-geni: Add shutdown callback for i2c Roja Rani Yarubandi
2021-01-12 7:30 ` Akash Asthana
2021-01-13 6:54 ` Stephen Boyd
2021-02-18 14:15 ` rojay
2021-02-24 7:06 ` Stephen Boyd
2021-02-24 9:20 ` Wolfram Sang
2021-04-20 11:12 ` rojay [this message]
2021-03-01 19:59 ` [PATCH V8 0/1] Implement Shutdown callback for geni-i2c patchwork-bot+linux-arm-msm
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=30d8e3661c37c7d2580ac1f03e254680@codeaurora.org \
--to=rojay@codeaurora.org \
--cc=agross@kernel.org \
--cc=akashast@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=dianders@chromium.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mka@chromium.org \
--cc=msavaliy@qti.qualcomm.com \
--cc=rnayak@codeaurora.org \
--cc=saiprakash.ranjan@codeaurora.org \
--cc=skakit@codeaurora.org \
--cc=sumit.semwal@linaro.org \
--cc=swboyd@chromium.org \
--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;
as well as URLs for NNTP newsgroup(s).