[PATCH] iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set

[PATCH] iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set

[Maxim Kochetkov]

To stop conversion ads1015_set_power_state function use unimplemented
function pm_runtime_put_autosuspend if CONFIG_PM is not set.
If CONFIG_PM is disabled, there is no need to start/stop conversion.
Fix it by adding return 0 function variant if CONFIG_PM is not set.

Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
---
 drivers/iio/adc/ti-ads1015.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/iio/adc/ti-ads1015.c b/drivers/iio/adc/ti-ads1015.c
index 5ea4f45d6bad..64fe3b2a6ec6 100644
--- a/drivers/iio/adc/ti-ads1015.c
+++ b/drivers/iio/adc/ti-ads1015.c
@@ -316,6 +316,7 @@ static const struct iio_chan_spec ads1115_channels[] = {
 	IIO_CHAN_SOFT_TIMESTAMP(ADS1015_TIMESTAMP),
 };
 
+#ifdef CONFIG_PM
 static int ads1015_set_power_state(struct ads1015_data *data, bool on)
 {
 	int ret;
@@ -333,6 +334,15 @@ static int ads1015_set_power_state(struct ads1015_data *data, bool on)
 	return ret < 0 ? ret : 0;
 }
 
+#else /* !CONFIG_PM */
+
+static int ads1015_set_power_state(struct ads1015_data *data, bool on)
+{
+	return 0;
+}
+
+#endif /* !CONFIG_PM */
+
 static
 int ads1015_get_adc_result(struct ads1015_data *data, int chan, int *val)
 {
-- 
2.27.0

Re: [PATCH] iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set

[Andy Shevchenko]

On Wed, Jul 29, 2020 at 10:59:07AM +0300, Maxim Kochetkov wrote:
> To stop conversion ads1015_set_power_state function use unimplemented
> function pm_runtime_put_autosuspend if CONFIG_PM is not set.
> If CONFIG_PM is disabled, there is no need to start/stop conversion.
> Fix it by adding return 0 function variant if CONFIG_PM is not set.

I'm wondering if you check the real code (assembly) for any difference.

All calls AFAICS are statically defined in !CONFIG_PM case and compiler/linker
should be clever enough to drop this completely. Isn't it the case?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set

[Maxim Kochetkov]

In case of CONFIG_PM is not set:

static inline int __pm_runtime_suspend(struct device *dev, int rpmflags)
{
	return -ENOSYS;
}

and ads1015_read_raw failed at:

		ret = ads1015_set_power_state(data, false);
		if (ret < 0)
			goto release_direct;

29.07.2020 11:21, Andy Shevchenko wrote:
> On Wed, Jul 29, 2020 at 10:59:07AM +0300, Maxim Kochetkov wrote:
>> To stop conversion ads1015_set_power_state function use unimplemented
>> function pm_runtime_put_autosuspend if CONFIG_PM is not set.
>> If CONFIG_PM is disabled, there is no need to start/stop conversion.
>> Fix it by adding return 0 function variant if CONFIG_PM is not set.
> 
> I'm wondering if you check the real code (assembly) for any difference.
> 
> All calls AFAICS are statically defined in !CONFIG_PM case and compiler/linker
> should be clever enough to drop this completely. Isn't it the case?
> 

Re: [PATCH] iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set

[Andy Shevchenko]

On Wed, Jul 29, 2020 at 11:26:51AM +0300, Maxim Kochetkov wrote:
> In case of CONFIG_PM is not set:
> 
> static inline int __pm_runtime_suspend(struct device *dev, int rpmflags)
> {
> 	return -ENOSYS;
> }
> 
> and ads1015_read_raw failed at:
> 
> 		ret = ads1015_set_power_state(data, false);
> 		if (ret < 0)
> 			goto release_direct;
> 

I see. Please, elaborate all this in the commit message for v2.

P.S. Avoid top postings!

> 29.07.2020 11:21, Andy Shevchenko wrote:
> > On Wed, Jul 29, 2020 at 10:59:07AM +0300, Maxim Kochetkov wrote:
> > > To stop conversion ads1015_set_power_state function use unimplemented
> > > function pm_runtime_put_autosuspend if CONFIG_PM is not set.
> > > If CONFIG_PM is disabled, there is no need to start/stop conversion.
> > > Fix it by adding return 0 function variant if CONFIG_PM is not set.
> > 
> > I'm wondering if you check the real code (assembly) for any difference.
> > 
> > All calls AFAICS are statically defined in !CONFIG_PM case and compiler/linker
> > should be clever enough to drop this completely. Isn't it the case?
> > 

-- 
With Best Regards,
Andy Shevchenko