From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.zx2c4.com (lists.zx2c4.com [165.227.139.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 37363C43334 for ; Wed, 29 Jun 2022 17:01:52 +0000 (UTC) Received: by lists.zx2c4.com (OpenSMTPD) with ESMTP id 7e7588bf; Wed, 29 Jun 2022 17:00:34 +0000 (UTC) Received: from sin.source.kernel.org (sin.source.kernel.org [2604:1380:40e1:4800::1]) by lists.zx2c4.com (OpenSMTPD) with ESMTPS id 64e0a84a (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO) for ; Wed, 29 Jun 2022 17:00:32 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 9FFE3CE2487; Wed, 29 Jun 2022 17:00:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8CD3CC341C8; Wed, 29 Jun 2022 17:00:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1656522028; bh=aX6BCoyP074w+Ec32Bjgq5Qkv6gXDTg4rIpA4hIZ24A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R/8KZZghPox1N6AUR6ZBSE/xv+dAqlVuAlzzf1S3mFLPeMy9gjW81Qyqgj5hKtmh0 gOq8T3dJN9HtFzu4y60WkiX/h+42A8rz4ss6j7sQqCOugsHjUjiiA0TCDfIx5GZwcg zjgxIcHxyzUujwVKft4QczxAtQNI2V1YozgZ1JTI= Date: Wed, 29 Jun 2022 19:00:25 +0200 From: Greg Kroah-Hartman To: "Jason A. Donenfeld" Cc: Christoph Hellwig , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Christian Brauner , Hridya Valsaraju , Suren Baghdasaryan , Theodore Ts'o , "David S. Miller" , Eric Dumazet , Jakub Kicinski , "Alex Xu (Hello71)" , Paolo Abeni , Rob Herring , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Shuah Khan , LKML , WireGuard mailing list , Netdev , rcu@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH] remove CONFIG_ANDROID Message-ID: References: <20220629150102.1582425-2-hch@lst.de> <20220629161020.GA24891@lst.de> <20220629161527.GA24978@lst.de> <20220629163007.GA25279@lst.de> <20220629164543.GA25672@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" 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 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