linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Deepak Kumar Singh <deesin@codeaurora.org>
To: Stephen Boyd <swboyd@chromium.org>,
	Sibi Sankar <sibis@codeaurora.org>,
	bjorn.andersson@linaro.org
Cc: agross@kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, manivannan.sadhasivam@linaro.org,
	Chris Lew <clew@codeaurora.org>
Subject: Re: [PATCH v4 1/2] soc: qcom: aoss: Expose send for generic usecase
Date: Fri, 23 Jul 2021 15:21:50 +0530	[thread overview]
Message-ID: <eaa90fa6-e7a4-169d-4ac0-42f8c9545a5b@codeaurora.org> (raw)
In-Reply-To: <CAE-0n506v5cmyUb+Ge-H7t1HsqNatgxDmq28rqdyGZDbsM4pXg@mail.gmail.com>


On 7/21/2021 12:07 PM, Stephen Boyd wrote:
> Quoting Sibi Sankar (2021-06-09 04:18:51)
>> From: Deepak Kumar Singh <deesin@codeaurora.org>
>>
>> Not all upcoming usecases will have an interface to allow the aoss
>> driver to hook onto. Expose the send api and create a get function to
>> enable drivers to send their own messages to aoss.
>>
>> Signed-off-by: Chris Lew <clew@codeaurora.org>
>> Signed-off-by: Deepak Kumar Singh <deesin@codeaurora.org>
>> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>
>> v4:
>>   * Fix compilation error due to missing qmp_put
>>   * Minor typos [s/tarcks/tracks]
>>
>>   drivers/soc/qcom/qcom_aoss.c       | 70 ++++++++++++++++++++++++++++++++++++--
>>   include/linux/soc/qcom/qcom_aoss.h | 36 ++++++++++++++++++++
>>   2 files changed, 104 insertions(+), 2 deletions(-)
>>   create mode 100644 include/linux/soc/qcom/qcom_aoss.h
>>
>> diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
>> index 934fcc4d2b05..e8f48760bac8 100644
>> --- a/drivers/soc/qcom/qcom_aoss.c
>> +++ b/drivers/soc/qcom/qcom_aoss.c
>> @@ -522,13 +582,14 @@ static int qmp_probe(struct platform_device *pdev)
>>          int irq;
>>          int ret;
>>
>> -       qmp = devm_kzalloc(&pdev->dev, sizeof(*qmp), GFP_KERNEL);
>> +       qmp = kzalloc(sizeof(*qmp), GFP_KERNEL);
>>          if (!qmp)
>>                  return -ENOMEM;
>>
>>          qmp->dev = &pdev->dev;
>>          init_waitqueue_head(&qmp->event);
>>          mutex_init(&qmp->tx_lock);
>> +       kref_init(&qmp->refcount);
>>
>>          res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>          qmp->msgram = devm_ioremap_resource(&pdev->dev, res);
>> @@ -569,6 +630,8 @@ static int qmp_probe(struct platform_device *pdev)
>>
>>          platform_set_drvdata(pdev, qmp);
>>
>> +       atomic_set(&qmp->orphan, 0);
>> +
>>          return 0;
>>
>>   err_remove_qdss_clk:
>> @@ -577,6 +640,7 @@ static int qmp_probe(struct platform_device *pdev)
>>          qmp_close(qmp);
>>   err_free_mbox:
>>          mbox_free_channel(qmp->mbox_chan);
>> +       kfree(qmp);
>>
>>          return ret;
>>   }
>> @@ -590,7 +654,9 @@ static int qmp_remove(struct platform_device *pdev)
>>          qmp_cooling_devices_remove(qmp);
>>
>>          qmp_close(qmp);
>> +       atomic_set(&qmp->orphan, 1);
> This looks odd. Why are we letting the device be removed while it is in
> use by other drivers? Can't we pin the device with get_device() so it
> can't be removed and then prevent the driver from being removed until
> all the consumer drivers drop the reference, i.e. suppress sysfs unbind?
>
> Otherwise it looks like a generic problem that all provider devices,
> clks, regulators, gpios, etc. have to deal with and thus this
> hand-rolled mechanism can't be right.

As per my earlier discussion with Bjorn, device could be unbound using 
sysfs, in which case

remove() is called irrespective of whether any client driver is holding 
struct device reference

or not. That's why i have added separate refcount for qmp handle and 
marking it invalid if

qmp_remove() is called.

>>          mbox_free_channel(qmp->mbox_chan);
>> +       kref_put(&qmp->refcount, qmp_handle_release);
>>
>>          return 0;
>>   }

  reply	other threads:[~2021-07-23  9:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-09 11:18 [PATCH v4 0/2] soc: qcom: aoss: Expose send for generic usecase Sibi Sankar
2021-06-09 11:18 ` [PATCH v4 1/2] " Sibi Sankar
2021-07-21  6:37   ` Stephen Boyd
2021-07-23  9:51     ` Deepak Kumar Singh [this message]
2021-07-23 19:28       ` Stephen Boyd
2021-06-09 11:18 ` [PATCH v4 2/2] soc: qcom: aoss: Add debugfs entry Sibi Sankar
2021-08-04 19:06   ` Bjorn Andersson
2021-06-14 10:21 [PATCH V4 0/2] soc: qcom: aoss: Expose send for generic usecase Deepak Kumar Singh
2021-06-14 10:21 ` [PATCH V4 1/2] " Deepak Kumar Singh

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=eaa90fa6-e7a4-169d-4ac0-42f8c9545a5b@codeaurora.org \
    --to=deesin@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=clew@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=sibis@codeaurora.org \
    --cc=swboyd@chromium.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).