From: Jishnu Prakash <quic_jprakash@quicinc.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
<conor+dt@kernel.org>, <andersson@kernel.org>,
<konrad.dybcio@linaro.org>, <lee@kernel.org>,
<andriy.shevchenko@linux.intel.com>, <daniel.lezcano@linaro.org>,
<dmitry.baryshkov@linaro.org>, <lars@metafoo.de>,
<luca@z3ntu.xyz>, <marijn.suijten@somainline.org>,
<agross@kernel.org>, <sboyd@kernel.org>, <rafael@kernel.org>,
<rui.zhang@intel.com>, <lukasz.luba@arm.com>,
<linus.walleij@linaro.org>, <quic_subbaram@quicinc.com>,
<quic_collinsd@quicinc.com>, <quic_amelende@quicinc.com>,
<quic_kamalw@quicinc.com>, <kernel@quicinc.com>,
<linux-kernel@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
<linux-arm-msm-owner@vger.kernel.org>,
<linux-iio@vger.kernel.org>, <linux-pm@vger.kernel.org>,
<devicetree@vger.kernel.org>,
<cros-qcom-dts-watchers@chromium.org>
Subject: Re: [PATCH v3 3/3] iio: adc: Add support for QCOM PMIC5 Gen3 ADC
Date: Fri, 16 Feb 2024 17:14:33 +0530 [thread overview]
Message-ID: <5dc98cf8-3146-400c-be2a-b0a1ec2368f7@quicinc.com> (raw)
In-Reply-To: <20240101175453.5807483a@jic23-huawei>
Hi Jonathan,
(Resending this mail for tracking on mailing lists, as it got rejected
from lists the first time due to HTML)
On 1/1/2024 11:24 PM, Jonathan Cameron wrote:
> On Sun, 31 Dec 2023 22:42:37 +0530
> Jishnu Prakash <quic_jprakash@quicinc.com> wrote:
>
>> The ADC architecture on PMIC5 Gen3 is similar to that on PMIC5 Gen2,
>> with all SW communication to ADC going through PMK8550 which
>> communicates with other PMICs through PBS.
>>
>> +
>> + for (i = 0; i < adc->nchannels; i++) {
>> + bool upper_set = false, lower_set = false;
>> + int temp, offset;
>> + u16 code = 0;
>> +
>> + chan_prop = &adc->chan_props[i];
>> + offset = chan_prop->tm_chan_index;
>> +
>> + if (!chan_prop->adc_tm)
>> + continue;
>> +
>> + mutex_lock(&adc->lock);
>> + if (chan_prop->sdam_index != sdam_index) {
>
> Perhaps factor this block out as indent already high and adding scoped_guard would
> make it worse.
I don't think I can completely factor it out, as we need to update
several local variables here (sdam_index, tm_status, buf, also chan_prop
above), but I'll try to reduce it as much as possible.
>
>> + sdam_index = chan_prop->sdam_index;
>> + ret = adc5_gen3_read(adc, sdam_index, ADC5_GEN3_TM_HIGH_STS,
>> + tm_status, 2);
>> + if (ret) {
>> + dev_err(adc->dev, "adc read TM status failed with %d\n", ret);
>> + goto out;
>> + }
>> +
>> +static void adc5_gen3_disable(void *data)
>> +{
>> + struct adc5_chip *adc = data;
>> + int i;
>> +
>> + if (adc->n_tm_channels)
>> + cancel_work_sync(&adc->tm_handler_work);
> If this is required before the place where a simple
> devm_request_irq() will result in the irqs being cleaned up
> them register this callback earlier to avoid problems there.
>
On checking again, it looks like I can just use devm_request_irq() and
avoid having to free irqs explicitly here and elsewhere. I'll still
need to call cancel_work_sync() and I think you have also asked me to
keep this call in another comment below. I have another question for it
below.
>> +
>> + for (i = 0; i < adc->num_sdams; i++)
>> + free_irq(adc->base[i].irq, adc);
>> +
>> + mutex_lock(&adc->lock);
>> + /* Disable all available TM channels */
>> + for (i = 0; i < adc->nchannels; i++) {
>> + if (!adc->chan_props[i].adc_tm)
>> + continue;
>> + adc5_gen3_poll_wait_hs(adc, adc->chan_props[i].sdam_index);
>> + _adc_tm5_gen3_disable_channel(&adc->chan_props[i]);
>> + }
>> +
>> + mutex_unlock(&adc->lock);
>> +}
>
>> +
>> + prop->hw_settle_time = VADC_DEF_HW_SETTLE_TIME;
>
> I'd prefer to see you has through the value that maps to this after qcom_adc5_hw_settle_time_from_dt
> so then you can just set a default in value and call the rest of the code unconditionally.
> Same for the cases that follow.
I can remove the return check for fwnode_property_read_u32() as you
suggested, but I think we still need to keep the return check for
qcom_adc5_hw_settle_time_from_dt(), to check in case values unsupported
in this ADC HW are set in DT. Same for the other properties.
>
>> + ret = fwnode_property_read_u32(fwnode, "qcom,hw-settle-time", &value);
>> + if (!ret) {
>> + ret = qcom_adc5_hw_settle_time_from_dt(value,
>> + data->hw_settle_1);
>> + if (ret < 0)
>> + return dev_err_probe(dev, ret, "%#x invalid hw-settle-time %d us\n",
>> + chan, value);
>> + prop->hw_settle_time = ret;
>> + }
>> +
>> +
>> + chan_props = adc->chan_props;
>> + adc->n_tm_channels = 0;
>> + iio_chan = adc->iio_chans;
>> + adc->data = device_get_match_data(adc->dev);
>> + if (!adc->data)
>> + adc->data = &adc5_gen3_data_pmic;
>
> Why do you need a default? Add a comment so we remember the reasoning.
On second thought, this may not be needed, I'll remove this.
>
>
>> +
>> + device_for_each_child_node(adc->dev, child) {
>> + ret = adc5_gen3_get_fw_channel_data(adc, chan_props, child, adc->data);
>> + if (ret < 0) {
>> +
>> + ret = platform_get_irq_byname(pdev, adc->base[i].irq_name);
>> + if (ret < 0) {
>> + kfree(reg);
>> + dev_err(dev, "Getting IRQ %d by name failed, ret = %d\n",
>> + adc->base[i].irq, ret);
>> + goto err_irq;
>> + }
>> + adc->base[i].irq = ret;
>> +
>> + ret = request_irq(adc->base[i].irq, adc5_gen3_isr, 0, adc->base[i].irq_name, adc);
>
> Don't mix devm and non dev calls. And don't group up multiple things in one devm callback
> as it almost always leads to bugs where for example only some irqs are allocated.
I can replace request_irq() with devm_request_irq(). But when you say
not to group up multiple things in one devm callback, do you mean the
devm_add_action() callback I added below or something else right here?
>
>> + if (ret < 0) {
>> + kfree(reg);
>> + dev_err(dev, "Failed to request SDAM%d irq, ret = %d\n", i, ret);
>> + goto err_irq;
>> + }
>> + }
>> + kfree(reg);
>
> I would factor out this code and allocation of reg so you can easily use scope
> based cleanup (see linux/cleanup.h) to avoid the kfree(reg) entries that
> make for awkward code flow.
>
The kfrees are not really needed, I'll just use devm_kcalloc to allocate
memory for the "reg" variable. With this and devm_request_irq, I think a
scoped guard would not be needed here.
>
>
>> +
>> + ret = devm_add_action(dev, adc5_gen3_disable, adc);
> As above, this action does multiple things. Also use devm_add_action_or_reset() to cleanup
> if the devm registration fails without needing to do it manually.
I'll change it to devm_add_action_or_reset(), but do you mean I should
call devm_add_action_or_reset() twice to register two separate callbacks
instead of just adc5_gen3_disable? Like one for calling
cancel_work_sync() alone and the other for the loop where we disable all
TM channels?
>
>> + if (ret < 0) {
>> + dev_err(dev, "failed to register adc disablement devm action, %d\n", ret);
>> + goto err_irq;
>> + }
>> +
>> +
>> + if (adc->n_tm_channels)
>> + INIT_WORK(&adc->tm_handler_work, tm_handler_work);
>
> Until this init work seems unlikely you should be calling the cancel
> work in gen3_disable()
We are already calling cancel_work_sync() in adc5_gen3_disable....is
there any change needed?
I'll address all your other comments in the next patchset.
Thanks,
Jishnu
>
>
>> +
>> + indio_dev->name = pdev->name;
>> + indio_dev->modes = INDIO_DIRECT_MODE;
>> + indio_dev->info = &adc5_gen3_info;
>> + indio_dev->channels = adc->iio_chans;
>> + indio_dev->num_channels = adc->nchannels;
>> +
>> + ret = devm_iio_device_register(dev, indio_dev);
>> + if (!ret)
>> + return 0;
> Please keep error conditions as the out of line path.
>
> if (ret)
> goto err_irq;
>
> return 0;
>
>
>> +
>> +err_irq:
>> + for (i = 0; i < adc->num_sdams; i++)
>> + free_irq(adc->base[i].irq, adc);
>
> Already freed by a devm cleanup handler.
>
>> +
>> + return ret;
>> +}
>
next prev parent reply other threads:[~2024-02-16 11:45 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-31 17:12 [PATCH v3 0/3] iio: adc: Add support for QCOM SPMI PMIC5 Gen3 ADC Jishnu Prakash
2023-12-31 17:12 ` [PATCH v3 1/3] dt-bindings: iio/adc: Move QCOM ADC bindings to iio/adc folder Jishnu Prakash
2024-01-01 10:35 ` kernel test robot
2024-01-04 8:08 ` Krzysztof Kozlowski
2023-12-31 17:12 ` [PATCH v3 2/3] dt-bindings: iio: adc: Add support for QCOM PMIC5 Gen3 ADC Jishnu Prakash
2023-12-31 17:41 ` Dmitry Baryshkov
2024-01-01 18:02 ` Jonathan Cameron
2024-02-16 10:39 ` Jishnu Prakash
2024-02-16 13:45 ` Jonathan Cameron
2024-01-04 8:18 ` Krzysztof Kozlowski
2024-02-16 11:44 ` Jishnu Prakash
2024-02-17 14:15 ` Krzysztof Kozlowski
[not found] ` <13f2b558-a50d-44d3-85de-38e230212732@quicinc.com>
2024-02-16 10:48 ` Dmitry Baryshkov
2024-02-16 11:18 ` Jishnu Prakash
2024-02-17 14:13 ` Krzysztof Kozlowski
2024-02-21 5:36 ` Jishnu Prakash
2024-02-21 7:19 ` Krzysztof Kozlowski
2024-03-14 8:28 ` Jishnu Prakash
2024-03-14 8:36 ` Krzysztof Kozlowski
2023-12-31 17:12 ` [PATCH v3 3/3] " Jishnu Prakash
2023-12-31 17:46 ` Dmitry Baryshkov
2024-02-14 13:58 ` Jishnu Prakash
2024-02-16 10:52 ` Dmitry Baryshkov
2023-12-31 19:54 ` kernel test robot
2024-01-01 17:54 ` Jonathan Cameron
2024-02-16 11:44 ` Jishnu Prakash [this message]
[not found] ` <b02f20fd-c682-4b47-8d61-1d0e2adbdd57@quicinc.com>
2024-02-16 13:54 ` Jonathan Cameron
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=5dc98cf8-3146-400c-be2a-b0a1ec2368f7@quicinc.com \
--to=quic_jprakash@quicinc.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=conor+dt@kernel.org \
--cc=cros-qcom-dts-watchers@chromium.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=jic23@kernel.org \
--cc=kernel@quicinc.com \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luca@z3ntu.xyz \
--cc=lukasz.luba@arm.com \
--cc=marijn.suijten@somainline.org \
--cc=quic_amelende@quicinc.com \
--cc=quic_collinsd@quicinc.com \
--cc=quic_kamalw@quicinc.com \
--cc=quic_subbaram@quicinc.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
--cc=rui.zhang@intel.com \
--cc=sboyd@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