Linux IIO development
 help / color / mirror / Atom feed
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;
>> +}
> 

  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