Re: [tpmdd-devel] [PATCH 3/4] tpm: Convert tpm_tis driver to usedev_pm_ops from legacy pm_ops

[Shuah Khan]

Hi Peter,

On 07/10/2013 05:30 PM, Peter Hüwe wrote:

>>
>> tpm_tis_resume() is defined originally in CONFIG_PM_SLEEP scope. I can
>> make the change to have tpm_tis_resume() not be in CONFIG_PM_SLEEP scope
>> and remove this CONFIG_PM_SLEEP when defining .pm.
>> That does make sense looking at tpm_pm_suspend() and tpm_pm_resume() which
>> are defined ithout CONFIG_PM_SLEEP scope. Sounds like the right approach?
>> I will redo the patch and send v2.
>
> Hmm,
> at first I thought that would be a good idea, however scrolling to the git
> history I found:
>
> commit 07368d32f1a67e797def08cf2ee3ea1647b204b6
> Author: Rafael J. Wysocki <rjw@xxxxxxx>
> Date:   Thu Aug 9 23:00:35 2012 +0200
>
>      tpm_tis / PM: Fix unused function warning for CONFIG_PM_SLEEP
>
>      According to a compiler warning, the tpm_tis_resume() function is not
>      used for CONFIG_PM_SLEEP unset, so add a #ifdef to prevent it from
>      being built in that case.
>
>      Signed-off-by: Rafael J. Wysocki <rjw@xxxxxxx>
>
> So removing it there would effectively revert the patch and re-enable the
> warning.
>
>
>
>> I find that the use of CONFIG_PM, CONFIG_PM_SLEEP, and CONFIG_PM_RUNTIME
>> are not very consistent. :)
> Yes.
>
> Maybe the better idea is to add the correct CONFIG_PM ifdefs for all code
> paths related to PM.
> Or leave the CONFIG_PM for tpm_tis_resume as it is.
>
>

For now, leaving tpm_tis_resume() is better to keep this change simpler. 
I am seeing this type of inconsistency in several drivers as I am going 
around making changes to convert from legacy pm_ops to dev_pm_ops. At 
some point, it might be worth while looking at the usage of these 
defines and set some clear guidelines.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research 
America (Silicon Valley) shuah.kh@xxxxxxxxxxx | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/