On Wed, Jun 29, 2022 at 06:52:08PM +0200, Jason A. Donenfeld wrote:
On Wed, Jun 29, 2022 at 6:45 PM Christoph Hellwig hch@lst.de wrote:
On Wed, Jun 29, 2022 at 06:38:09PM +0200, Jason A. Donenfeld wrote:
On the technical topic, an Android developer friend following this thread just pointed out to me that Android doesn't use PM_AUTOSLEEP and just has userspace causing suspend frequently. So by his rough estimation your patch actually *will* break Android devices. Zoinks. Maybe he's right, maybe he's not -- I don't know -- but you should probably look into this if you want this patch to land without breakage.
And it will also "break" anyone else doing frequent suspends from userspace, as that behavior is still in no way related to CONFIG_ANDROID.
I don't know of any actual systems that do this for which CONFIG_PM_AUTOSLEEP and CONFIG_ANDROID are both disabled. At least that was what I concluded back in 2017-2018 when I looked at this last. And so far, no other-handset-users have reported bugs.
But of course I agree that this all could be improved with something more granular somehow, somewhere. I don't really have any developed opinions on what that looks like or what form that should take.
However, the thing I do have a strong opinion on is that the change you're proposing shouldn't break things. And that's what your patch currently might do (or not!).
I think that by the time the next kernel release comes out, and percolates to a real Android device, the years gone by will have caused those who care about this to fix it.
In the meantime, this might actually fix issues in desktop distros that were enabling this option, thinking it only affected the building of a driver, not core power management functionality.
So it's nothing to worry about now, I agree with Christoph, this config option should not be used for power management policy decisions like this. This should be controlled by userspace properly in the Android userspace framework, like all other Linux distros/systems do this.
And worst case, Android kernels sometimes _do_ have a not-upstream config option that you can use to trigger off of horrible hacks like this. I'll leave the answer to what that is as an exercise for the reader :)
thanks,
greg k-h