From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBouqPByYLbc/+TWcaQflHNUCWEn5npku6pLUIIOPU7THREgllGfEtOx4OJd8yPGr2sFGnSkz ARC-Seal: i=1; a=rsa-sha256; t=1516283040; cv=none; d=google.com; s=arc-20160816; b=JrO9NGFdmb+XvZgxvM44jAbV5c96Zk6XX90EZKKaWwjZY9VQEnET03/mIiCRRcCiTU 2NCD3bJb4q/USqw2N2Td0On76FZ7Gj9eN9Zh536vrMpWUtTJBULKpwblvoRX2ipnErGv wVs0p4lMlOHBO6PA3NY2OtJOZQh2n8Sh19ktlNZ/76JsGgchxeiZNHVVd1zYolj+OCks kVuWouZBYVSdcrnxhQNDMg58SkC3awTcVhonw/JEAxNvES7x1fQW++3AGsD+09BPgqrc sNew+xeWs0SoUoYCZZ324UhNBY8c+DFOKKnI6NP3vsBKBFnfZCKLbPjKtG18dMOcRUZj jtow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:dkim-signature :arc-authentication-results; bh=IP+CmA9b8Tpd0GWnc6H0++3fwVYlOoc0gD+qp15FhK4=; b=bUAyyau0gCKdDnCCP3etQS8CFurollaxIo6u7BjOPEFRvsPFcetKJ0OA9QVotaPLY+ xjN9Db5wSPHx9GfUIQjWjZcv7yocOqtfx6pOuRVRzzS2Ta0qMyJStTOrBFMbcQHA6Z96 FXtNJ4jUcaHQLE1nDearMiPcl3GzduaW6WwI1m1k1XZFfxqfnRZ7htFwFRs19gLFsJAy kmJq1CCtMIlY4lEwNJD83VPADHvTv2fZMGslLN1vDi9xuDW1K/I4Q3nmNqcbpkCqx/Q6 BllJtVR9DSIAcmJhyRI9dUwCt+5ReiVwV9Uv3tcxnsFPXe3t3PbF1DuLBEJAHmQ6BkKD 3lRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@goldelico.com header.s=strato-dkim-0002 header.b=BpiFy5vU; spf=neutral (google.com: 2a01:238:20a:202:5300::1 is neither permitted nor denied by best guess record for domain of hns@goldelico.com) smtp.mailfrom=hns@goldelico.com Authentication-Results: mx.google.com; dkim=pass header.i=@goldelico.com header.s=strato-dkim-0002 header.b=BpiFy5vU; spf=neutral (google.com: 2a01:238:20a:202:5300::1 is neither permitted nor denied by best guess record for domain of hns@goldelico.com) smtp.mailfrom=hns@goldelico.com X-RZG-AUTH: :JGIXVUS7cutRB/49FwqZ7WcJeFKiMgPgp8VKxflSZ1P34KBj4Qpw87WisNN2EjyY X-RZG-CLASS-ID: mo00 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver From: "H. Nikolaus Schaller" In-Reply-To: <20180118061314.GG3286@localhost> Date: Thu, 18 Jan 2018 14:43:03 +0100 Cc: Mark Rutland , DTML , Discussions about the Letux Kernel , Arnd Bergmann , Tony Lindgren , Greg Kroah-Hartman , kernel@pyra-handheld.com, Russell King , Linux Kernel Mailing List , linux-omap , Rob Herring , Linux ARM , =?utf-8?Q?Beno=C3=AEt_Cousson?= , Kevin Hilman , Andreas Kemnade , Thierry Reding , =?utf-8?Q?Andreas_F=C3=A4rber?= , Jonathan Cameron Content-Transfer-Encoding: quoted-printable Message-Id: <8B2641B8-E86B-425C-9E79-E9C41E4E623C@goldelico.com> References: <5494ad34b39a6c62601e3747440268dfb3be7d5a.1512114576.git.hns@goldelico.com> <20171222124427.GI3374@localhost> <91850CC3-B280-4701-9D07-96AFF3A79A6F@goldelico.com> <90F9A8E4-035A-4A9E-8AAB-757491D63E69@goldelico.com> <20180112153903.GB5992@localhost> <20180118061314.GG3286@localhost> To: Johan Hovold X-Mailer: Apple Mail (2.3124) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1584169666984958099?= X-GMAIL-MSGID: =?utf-8?q?1589938005677711389?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: Hi Johan, > Am 18.01.2018 um 07:13 schrieb Johan Hovold : >=20 > Hacks are never good, but sometimes needed. But we should try to keep > them contained in drivers rather than allow them to spread to core = code, > was what I was trying to say above. Well, aren't we talking here about a well isolated driver? And not about core code? Core code already provides everything to build a driver for this chip to make us happy with. It is just not yet providing a generic gps interface API to make = everybody happy with. >> That is what Andreas did remark as motivation: provide a solution >> for *existing* user spaces. >=20 > I understand that this is what you want, but that in itself is not a > sufficient reason to put something in the kernel. Agreed, but it is a secondary (but still strong) motivation, not the = primary one. >=20 >>>> - can not guarantee (!) to power off the chip if the last = user-space >>>> process using it is killed (which is essential for power-management = of >>>> a handheld, battery operated device) >>>=20 >>> That depends on how you implement things (extending gpsd, wrapper >>> script, pty daemon, ...). >>=20 >> No. You can of course cover all standard cases but there is one = fundamental >> issue which is IMHO a problem of any user-space implementation: >>=20 >> How can you guarantee that the chip is powered off if no >> user-space process is using it or if the last process doing >> this is killed by *whatever* reason? >>=20 >> E.g. after a kill -9. Or if someone deinstalls gpsd or whatever and = assumes >> (and wants a guarantee) that GPS is now turned off and never turned = on drawing >> precious milliamps from the battery for no use. >=20 > Have something run at init to put the device in a low power state. This does *not* solve the issue how to *guarantee* that it becomes powered off if the number of user-space processes goes down to zero *after* init. Please consider that a portable device is rarely booted but might be operated over several days with many suspend cycles. And people may still expect that the power consumer "GPS" is turned off if their personal user-space setup simply kills gpsd. >=20 >> As it is well known, a user-space process can't protect itself = against kill -9. >> Or has this recently been changed and I am not aware of? >>=20 >> This is the fundamental reason why we need a kernel driver to provide >> reliable, repeatable and trustable power management of this chip. >>=20 >> It is equally fundamental as a hard disk should spin down after the = last >> file is closed. Even if this process ends by a kill -9. Please advise how we should solve this fundamental problem in = user-space. >>=20 >> This seems to contradict your argument that user-space can very = easily >> adapt to everything. If the latter were true there would be no need = to >> keep old interfaces supported for a long time. >=20 > You probably know that we try hard never to change an interface that > would break user space, and that's why we need to get it right. Yes, I know and agree that it is very important (and difficult to = achieve). But it seems that there are different opinions of what "right" is... You seem to focus on the "right" API only (where we agree that the = "right" API does not exist and likely will never come or at least in the near = future). But for us the whole combination of kernel + user-space must behave = "right" (and use a function split that allows to optimally achieve this goal). >=20 >> So can you agree to that a battery powered portable device must have >> reliable and trustable power management? And if it provable can't be >> implemented in user-space (a single counter example suffices) it must >> be a kernel driver? >=20 > Having a kernel driver would make things easier for user space, sure, > but again, that's not a sufficient reason to merge just any kernel > implementation. It is not about "easier" for anyone. Neither for you nor for me. For us it would be much easier not to have to run this never-ending discussion over and over... It is about making it technically fully "reliable". And not 99% as per quick and dirty user-space hacks. It is so easy to invent scenarios in user-space to make the device = practically unusable by unnoticed draining a full battery within less than a day = when not perfectly turning off the chip power. So if a kernel driver can better protect users against this situation = for a portable device with this chip, why shouldn't it do with a handful = LOC? What requirement is more important than this? BR and thanks, Nikolaus From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Nikolaus Schaller" Subject: Re: [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver Date: Thu, 18 Jan 2018 14:43:03 +0100 Message-ID: <8B2641B8-E86B-425C-9E79-E9C41E4E623C@goldelico.com> References: <5494ad34b39a6c62601e3747440268dfb3be7d5a.1512114576.git.hns@goldelico.com> <20171222124427.GI3374@localhost> <91850CC3-B280-4701-9D07-96AFF3A79A6F@goldelico.com> <90F9A8E4-035A-4A9E-8AAB-757491D63E69@goldelico.com> <20180112153903.GB5992@localhost> <20180118061314.GG3286@localhost> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180118061314.GG3286@localhost> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Johan Hovold Cc: Mark Rutland , DTML , linux-omap , Jonathan Cameron , Arnd Bergmann , Tony Lindgren , Greg Kroah-Hartman , Russell King , Linux Kernel Mailing List , Thierry Reding , Rob Herring , Kevin Hilman , =?utf-8?Q?Beno=C3=AEt_Cousson?= , kernel@pyra-handheld.com, Andreas Kemnade , Discussions about the Letux Kernel , =?utf-8?Q?Andreas_F=C3=A4rber?= , Linux ARM List-Id: devicetree@vger.kernel.org Hi Johan, > Am 18.01.2018 um 07:13 schrieb Johan Hovold : > > Hacks are never good, but sometimes needed. But we should try to keep > them contained in drivers rather than allow them to spread to core code, > was what I was trying to say above. Well, aren't we talking here about a well isolated driver? And not about core code? Core code already provides everything to build a driver for this chip to make us happy with. It is just not yet providing a generic gps interface API to make everybody happy with. >> That is what Andreas did remark as motivation: provide a solution >> for *existing* user spaces. > > I understand that this is what you want, but that in itself is not a > sufficient reason to put something in the kernel. Agreed, but it is a secondary (but still strong) motivation, not the primary one. > >>>> - can not guarantee (!) to power off the chip if the last user-space >>>> process using it is killed (which is essential for power-management of >>>> a handheld, battery operated device) >>> >>> That depends on how you implement things (extending gpsd, wrapper >>> script, pty daemon, ...). >> >> No. You can of course cover all standard cases but there is one fundamental >> issue which is IMHO a problem of any user-space implementation: >> >> How can you guarantee that the chip is powered off if no >> user-space process is using it or if the last process doing >> this is killed by *whatever* reason? >> >> E.g. after a kill -9. Or if someone deinstalls gpsd or whatever and assumes >> (and wants a guarantee) that GPS is now turned off and never turned on drawing >> precious milliamps from the battery for no use. > > Have something run at init to put the device in a low power state. This does *not* solve the issue how to *guarantee* that it becomes powered off if the number of user-space processes goes down to zero *after* init. Please consider that a portable device is rarely booted but might be operated over several days with many suspend cycles. And people may still expect that the power consumer "GPS" is turned off if their personal user-space setup simply kills gpsd. > >> As it is well known, a user-space process can't protect itself against kill -9. >> Or has this recently been changed and I am not aware of? >> >> This is the fundamental reason why we need a kernel driver to provide >> reliable, repeatable and trustable power management of this chip. >> >> It is equally fundamental as a hard disk should spin down after the last >> file is closed. Even if this process ends by a kill -9. Please advise how we should solve this fundamental problem in user-space. >> >> This seems to contradict your argument that user-space can very easily >> adapt to everything. If the latter were true there would be no need to >> keep old interfaces supported for a long time. > > You probably know that we try hard never to change an interface that > would break user space, and that's why we need to get it right. Yes, I know and agree that it is very important (and difficult to achieve). But it seems that there are different opinions of what "right" is... You seem to focus on the "right" API only (where we agree that the "right" API does not exist and likely will never come or at least in the near future). But for us the whole combination of kernel + user-space must behave "right" (and use a function split that allows to optimally achieve this goal). > >> So can you agree to that a battery powered portable device must have >> reliable and trustable power management? And if it provable can't be >> implemented in user-space (a single counter example suffices) it must >> be a kernel driver? > > Having a kernel driver would make things easier for user space, sure, > but again, that's not a sufficient reason to merge just any kernel > implementation. It is not about "easier" for anyone. Neither for you nor for me. For us it would be much easier not to have to run this never-ending discussion over and over... It is about making it technically fully "reliable". And not 99% as per quick and dirty user-space hacks. It is so easy to invent scenarios in user-space to make the device practically unusable by unnoticed draining a full battery within less than a day when not perfectly turning off the chip power. So if a kernel driver can better protect users against this situation for a portable device with this chip, why shouldn't it do with a handful LOC? What requirement is more important than this? BR and thanks, Nikolaus From mboxrd@z Thu Jan 1 00:00:00 1970 From: hns@goldelico.com (H. Nikolaus Schaller) Date: Thu, 18 Jan 2018 14:43:03 +0100 Subject: [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver In-Reply-To: <20180118061314.GG3286@localhost> References: <5494ad34b39a6c62601e3747440268dfb3be7d5a.1512114576.git.hns@goldelico.com> <20171222124427.GI3374@localhost> <91850CC3-B280-4701-9D07-96AFF3A79A6F@goldelico.com> <90F9A8E4-035A-4A9E-8AAB-757491D63E69@goldelico.com> <20180112153903.GB5992@localhost> <20180118061314.GG3286@localhost> Message-ID: <8B2641B8-E86B-425C-9E79-E9C41E4E623C@goldelico.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Johan, > Am 18.01.2018 um 07:13 schrieb Johan Hovold : > > Hacks are never good, but sometimes needed. But we should try to keep > them contained in drivers rather than allow them to spread to core code, > was what I was trying to say above. Well, aren't we talking here about a well isolated driver? And not about core code? Core code already provides everything to build a driver for this chip to make us happy with. It is just not yet providing a generic gps interface API to make everybody happy with. >> That is what Andreas did remark as motivation: provide a solution >> for *existing* user spaces. > > I understand that this is what you want, but that in itself is not a > sufficient reason to put something in the kernel. Agreed, but it is a secondary (but still strong) motivation, not the primary one. > >>>> - can not guarantee (!) to power off the chip if the last user-space >>>> process using it is killed (which is essential for power-management of >>>> a handheld, battery operated device) >>> >>> That depends on how you implement things (extending gpsd, wrapper >>> script, pty daemon, ...). >> >> No. You can of course cover all standard cases but there is one fundamental >> issue which is IMHO a problem of any user-space implementation: >> >> How can you guarantee that the chip is powered off if no >> user-space process is using it or if the last process doing >> this is killed by *whatever* reason? >> >> E.g. after a kill -9. Or if someone deinstalls gpsd or whatever and assumes >> (and wants a guarantee) that GPS is now turned off and never turned on drawing >> precious milliamps from the battery for no use. > > Have something run at init to put the device in a low power state. This does *not* solve the issue how to *guarantee* that it becomes powered off if the number of user-space processes goes down to zero *after* init. Please consider that a portable device is rarely booted but might be operated over several days with many suspend cycles. And people may still expect that the power consumer "GPS" is turned off if their personal user-space setup simply kills gpsd. > >> As it is well known, a user-space process can't protect itself against kill -9. >> Or has this recently been changed and I am not aware of? >> >> This is the fundamental reason why we need a kernel driver to provide >> reliable, repeatable and trustable power management of this chip. >> >> It is equally fundamental as a hard disk should spin down after the last >> file is closed. Even if this process ends by a kill -9. Please advise how we should solve this fundamental problem in user-space. >> >> This seems to contradict your argument that user-space can very easily >> adapt to everything. If the latter were true there would be no need to >> keep old interfaces supported for a long time. > > You probably know that we try hard never to change an interface that > would break user space, and that's why we need to get it right. Yes, I know and agree that it is very important (and difficult to achieve). But it seems that there are different opinions of what "right" is... You seem to focus on the "right" API only (where we agree that the "right" API does not exist and likely will never come or at least in the near future). But for us the whole combination of kernel + user-space must behave "right" (and use a function split that allows to optimally achieve this goal). > >> So can you agree to that a battery powered portable device must have >> reliable and trustable power management? And if it provable can't be >> implemented in user-space (a single counter example suffices) it must >> be a kernel driver? > > Having a kernel driver would make things easier for user space, sure, > but again, that's not a sufficient reason to merge just any kernel > implementation. It is not about "easier" for anyone. Neither for you nor for me. For us it would be much easier not to have to run this never-ending discussion over and over... It is about making it technically fully "reliable". And not 99% as per quick and dirty user-space hacks. It is so easy to invent scenarios in user-space to make the device practically unusable by unnoticed draining a full battery within less than a day when not perfectly turning off the chip power. So if a kernel driver can better protect users against this situation for a portable device with this chip, why shouldn't it do with a handful LOC? What requirement is more important than this? BR and thanks, Nikolaus